Como probablemente sabrá, las fuentes del núcleo de linux son abiertas. Cualquiera puede obtenerlas, analizarlas y modificarlas. Este modelo de desarrollo abierto, que siguen tanto Linux como la mayoría de las aplicaciones que se ejecutan sobre él, conduce a altos niveles de seguridad. Es cierto que cualquiera puede acceder al código fuente para encontrar las debilidades, pero no es menos cierto que el tiempo que tarda en aparecer la solución para cualquier debilidad se mide más fácilmente en horas que en días.
Gracias a esto, Linux es conocido por su alto nivel de estabilidad que parte del propio núcleo del sistema operativo (lo que propiamente es Linux).
Servicios en Linux
Linux tiene disponible todos los servicios habituales en una red:
Bases de datos.
Servicios de Internet.
Servicio de ficheros e impresión.
Utilidades necesarias para mantener el nivel de seguridad requerido.
Pero además hay que reseñar que cada servicio funciona sin afectar al resto de los servicios. Vd. puede modificar la dirección IP de su equipo, las rutas, añadir, parar o reiniciar un servicio concreto sin que el resto de los servicios se vean afectados. Sólo es necesario detener el equipo para realizar operaciones con el hardware, como añadir un disco duro, o utilizar un nuevo núcleo. No tendrá, pues, la necesidad de tener que ser Vd. mismo el atacante de su propio sistema, a diferencia de lo que ocurre en otros sistemas operativos.
domingo, 10 de febrero de 2008
Seguridad Linux
Este documento abarca algunas de las principales cuestiones que afectan a la seguridad de Linux. Se discute la filosofía general y los recursos nacidos en la red. Otros muchos documentos COMO tocan cuestiones de seguridad y a esos documentos se apunta cuando es conveniente. Este documento no pretende ser un documento actualizado sobre exploits. Constantemente ocurren gran cantidad de nuevos exploits. Este documento te dirá dónde buscar esa información actualizada y dará algunos métodos generales para impedir que tengan lugar tales exploits. ¿Por qué necesitamos Seguridad? En el siempre cambiante mundo de las comunicaciones globales de datos, las conexiones baratas a Internet y el desarrollo de software de consumo rápido, la seguridad se está convirtiendo cada vez más en un problema. Ahora la seguridad es un requisito básico porque la computación global es inherentemente insegura. Cuando tus datos van desde el punto A al punto B sobre Internet, por ejemplo, pueden pasar a través de diversos otros puntos por el camino, dando a otros usuarios la oportunidad de interceptarlos e incluso de alterarlos. Además, otros usuarios de tu sistema de forma maliciosa pueden transformar tus datos en algo que tú no pretendes. Los intrusos, también conocidos como "crackers", pueden obtener acceso no autorizado a tu sistema y entonces usar conocimientos avanzados para hacerse pasar por tí, robarte información o incluso denegarte el acceso a tus propios recursos. Si te estás preguntando cuál es la diferencia entre un "Hacker" y un "Cracker", ver el documento de Eric Raymond, "How to Become A Hacker", disponible en http://sagan.earthspace.net/~esr/faqs/hacker-
¿Cuánto de Seguro es lo Seguro?
En primer lugar, hay que tener en cuenta que ningún sistema de computadores puede ser "completamente seguro". Todo lo que se puede hacer es que cada vez le sea más difícil a alguien comprometer tu sistema. Para el usuario doméstico medio de Linux, no se requiere mucho para mantener a raya al cracker casual. Para los usuarios de Linux de perfil alto (bancos, compañías de telecomunicaciones, etc), se requiere mucho más trabajo. Otro factor a tomar en cuenta es que mientras más seguro sea tu sistema, más intrusiva se convierte su seguridad. Necesitas decidir el punto de equilibrio en el que tu sistema seguirá siendo usable al tiempo que seguro para tus propósitos. Por ejemplo, puedes exigir a todo el que llama a tu sistema que use un modem de devolución de llamadas para rellamarlos a su número de casa. Esto es más seguro, pero si alguien no está en casa, se les hace difícil conectar. Se puede también establecer la configuración de tu sistema Linux sin red o sin conexión a Internet, pero esto limita su utilidad. Si estás en un sitio de tamaño medio a grande, debes definir una política de seguridad estableciendo cuánta seguridad se requiere en ese sitio y qué auditorías hay que poner en marcha para comprobarla. Se puede encontrar un ejemplo bien conocido de política de seguridad en http://ds.internic.net/rfc/rfc2196.txt. Ha sido recientemente puesta al día y contiene un buen marco para establecer una política de seguridad para tu empresa
¿Qué intentas proteger?
Antes de intentar asegurar tu sistema, debes delimitar contra qué nivel de amenaza tienes que protegerlo, qué riesgos debes o no debes asumir y cuán vulnerable resultará tu sistema. Debes analizar tu sistema para conocer qué estás protegiendo, por qué lo estás protegiendo, qué valor tiene y quién tiene responsabilidad sobre sus datos y otros activos.
El riesgo es la posibilidad de que un intruso pueda tener éxito en el intento de acceder a tu computador. ¿Puede un intruso leer o escribir archivos, o ejecutar programas que podrían causar daño? ¿Puede borrar datos criticos? ¿Puede impedirte a tí o a tu empresa obtener trabajo importante ya hecho? No lo olvides: alguien que logra acceso a tu cuenta, o a tu sistema, puede también suplantarte.
Además, tener una cuenta insegura en tu sistema puede dar como resultado que toda tu red se vea comprometida. Si permites a un sólo usuario conectarse usando un archivo .rhosts, o usar un servicio inseguro, tal como tftp, te arriesgas a que un intruso meta 'un pie en la puerta'. Una vez que el intruso tiene una cuenta de usuario en tu sistema, o en el sistema de cualquier otro, puede usarla para lograr acceso a otro sistema u otra cuenta.
La amenaza normalmente procede de alguien que tiene motivos para querer un acceso no autorizado a tu red o computador. Debes decidir en quiénes confías para darles acceso a tu sistema y qué amenazas podrían suponer.
Hay diversos tipos de intrusos y es útil tener en mente sus diferentes características a la hora de asegurar tus sistemas.
El Curioso - Este tipo de intruso está básicamente interesado en averiguar qué tipo de sistema y de datos tienes.
El Malicioso - Este tipo de intruso trata de hacer caer tus sistemas, o de deformar tu página web, o de hacerte gastar tiempo y dinero de cualquier modo para recuperarte del daño que te ha ocasionado.
El Intruso de Perfil-alto - Este tipo de intruso trata de usar tu sistema para lograr popularidad e infamia. Podría usar tu sistema de perfil alto para anunciar sus habilidades.
El Competidor - Este tipo de intruso está interesado en los datos que tienes en tu sistema. Podría ser alguien que piensa que tienes algo que podría beneficiarlo, financieramente o de otro modo.
Los Gorrones - Este tipo de intruso está interesado en establecer comercio en tu sistema y usar sus recursos para sus propios fines. Normalmente ejecutarán servidores de chat o irc, sitios de archivos porno o incluso servidores de DNS.
El Saltador - Este tipo de intruso está interesado en tu sistema sólo para usarlo como medio para entrar en otros sistemas. Si tu sistema está bien conectado o sirve de pasarela para un grupo de hosts internos, podrás fácilmente ver a este tipo intentando comprometer tu sistema.
La vulnerabilidad describe lo bien protegido que está tu computador de otra red, y la potencialidad de que alguien logre acceso no autorizado a él.
¿Qué es lo que está en juego si alguien irrumpe en tu sistema? Por supuesto, los intereses de un usuario doméstico PPP dinámico serán diferentes de los de una empresa que conecta su máquina a Internet u otra gran red.
¿Cuánto tiempo llevaría recuperar/recrear los datos perdidos? Una inversión inicial de tiempo ahora puede ahorrar diez veces más tiempo después si se tienen que recrear los datos perdidos. ¿Has comprobado tu estrategia de copias de seguridad y verificado tus datos últimamente?
El riesgo es la posibilidad de que un intruso pueda tener éxito en el intento de acceder a tu computador. ¿Puede un intruso leer o escribir archivos, o ejecutar programas que podrían causar daño? ¿Puede borrar datos criticos? ¿Puede impedirte a tí o a tu empresa obtener trabajo importante ya hecho? No lo olvides: alguien que logra acceso a tu cuenta, o a tu sistema, puede también suplantarte.
Además, tener una cuenta insegura en tu sistema puede dar como resultado que toda tu red se vea comprometida. Si permites a un sólo usuario conectarse usando un archivo .rhosts, o usar un servicio inseguro, tal como tftp, te arriesgas a que un intruso meta 'un pie en la puerta'. Una vez que el intruso tiene una cuenta de usuario en tu sistema, o en el sistema de cualquier otro, puede usarla para lograr acceso a otro sistema u otra cuenta.
La amenaza normalmente procede de alguien que tiene motivos para querer un acceso no autorizado a tu red o computador. Debes decidir en quiénes confías para darles acceso a tu sistema y qué amenazas podrían suponer.
Hay diversos tipos de intrusos y es útil tener en mente sus diferentes características a la hora de asegurar tus sistemas.
El Curioso - Este tipo de intruso está básicamente interesado en averiguar qué tipo de sistema y de datos tienes.
El Malicioso - Este tipo de intruso trata de hacer caer tus sistemas, o de deformar tu página web, o de hacerte gastar tiempo y dinero de cualquier modo para recuperarte del daño que te ha ocasionado.
El Intruso de Perfil-alto - Este tipo de intruso trata de usar tu sistema para lograr popularidad e infamia. Podría usar tu sistema de perfil alto para anunciar sus habilidades.
El Competidor - Este tipo de intruso está interesado en los datos que tienes en tu sistema. Podría ser alguien que piensa que tienes algo que podría beneficiarlo, financieramente o de otro modo.
Los Gorrones - Este tipo de intruso está interesado en establecer comercio en tu sistema y usar sus recursos para sus propios fines. Normalmente ejecutarán servidores de chat o irc, sitios de archivos porno o incluso servidores de DNS.
El Saltador - Este tipo de intruso está interesado en tu sistema sólo para usarlo como medio para entrar en otros sistemas. Si tu sistema está bien conectado o sirve de pasarela para un grupo de hosts internos, podrás fácilmente ver a este tipo intentando comprometer tu sistema.
La vulnerabilidad describe lo bien protegido que está tu computador de otra red, y la potencialidad de que alguien logre acceso no autorizado a él.
¿Qué es lo que está en juego si alguien irrumpe en tu sistema? Por supuesto, los intereses de un usuario doméstico PPP dinámico serán diferentes de los de una empresa que conecta su máquina a Internet u otra gran red.
¿Cuánto tiempo llevaría recuperar/recrear los datos perdidos? Una inversión inicial de tiempo ahora puede ahorrar diez veces más tiempo después si se tienen que recrear los datos perdidos. ¿Has comprobado tu estrategia de copias de seguridad y verificado tus datos últimamente?
Desarrollo de una Política de Seguridad
Desarrollo de una Política de Seguridad
Has de crear una política simple y genérica para tu sistema, que sus usuarios puedan fácilmente entender y seguir. Debe proteger los datos que estás salvaguardando así como la privacidad de los usuarios. Algunas cosas a considerar para añadir son: quién tiene acceso al sistema (¿puede mi amigo usar mi cuenta?), quién tiene permitido instalar software en el sistema, quién posee qué datos, la recuperación de desastres y el uso apropiado del sistema. Una política de seguridad generalmente aceptada comienza con la frase Lo que no está permitido está prohibido Esto significa que, a menos que tú concedas acceso a un servicio a un usuario, este usuario no podrá usar ese servicio hasta que tú le des acceso. Asgúrate de que las políticas funcionan en tu cuenta regular de usuario. Decir: "Ah, no puedo resolver este problema de permisos, lo haré como root" te puede llevar a agujeros de seguridad que son muy obvios, e incluso a algunos que no han sido explotados todavía. rfc1244 es un documento que describe cómo crear tu política de seguridad en tu propia red. rfc1281 es un documento que muestra un ejemplo de política de seguridad con descripciones detalladas de cada paso. Por último, podrías querer echar un vistazo al archivo de política del COAST en ftp://coast.cs.purdue.edu/pub/doc/policy para ver a qué se parecen algunas políticas de seguridad de la vida Medios de asegurar tu sitio Este documento discutirá diversos medios con los cuales puedes asegurar las cosas por las que has estado trabajando duro: tu equipo local, tus datos, tus usuarios, tu red e incluso tu reputación. ¿Qué le sucedería a tu reputación si un intruso borrara datos de algunos de tus usuarios? ¿O deformara tu sitio web? ¿O publicara el plan de proyecto corporativo para el próximo cuatrimestre de tu empresa? Si estás planificando la instalación de una red, hay muchos factores que debes tomar en cuenta antes de añadir una sola máquina a tu red. Aunque tengas una sola cuenta telefónica PPP, o sólo un pequeño sitio, esto no significa que los intrusos no estén interesados en tus sistemas. Los sitios grandes y de perfil alto no son los únicos objetivos -- muchos intrusos simplemente quieren reventar tantos sitios como les sea posible, sin que importe su tamaño. Además, pueden usar un agujero de seguridad en tu sitio para lograr acceso a otros sitios a los que estás conectado. Los intrusos tienen un montón de tiempo y pueden eludir averiguar cómo has oscurecido tu sistema intentando todas las posibilidades. Hay también otras muchas razones por las que un intruso puede estar interesado en tu sistema, que se discutirán Seguridad del Host Quizás el área de seguridad sobre la cual los administradores se concentran más es la seguridad base del host. Por lo general esto implica estar seguro de que tu propio sistema es seguro, y esperar que cualquier otro de tu red haga lo mismo. Elegir buenas contraseñas, asegurar los servicios de red local del host, mantener buenos registros de las cuentas y mejorar los programas con exploits de seguridad conocidos, están entre las cosas que el administrador de seguridad local tiene la responsabilidad de hacer. Aunque esto es completamente necesario, puede convertirse en una tarea desalentadora desde que tu red sea mayor de unas cuantas máquinas. Seguridad de la red La seguridad de la red es tan necesaria como la seguridad del host local. Con cientos, miles o más computadores en la misma red, no puedes confiar en que cada uno de estos sistemas sea seguro. Asegurarte de que sólo los usuarios autorizados pueden usar tu red, construir cortafuegos, usar encriptación fuerte y asegurarte de que no haya máquinas "rogue" (esto es, inseguras) en tu red, son parte los deberes de un administrador de seguridad de red. Este documento discutirá algunas de las técnicas usadas para asegurar tu sitio y esperamos enseñarte algunas maneras de impedir a un intruso lograr acceso a lo que estás tratando de proteger. Seguridad mediante Oscuridad Un tipo de seguridad que debe ser discutida es la "seguridad mediante oscuridad". Esto quiere decir, por ejemplo, mover un servicio vulnerable en seguridad a un puerto no estándar con la esperanza de que los atacantes no se den cuenta de que está ahí y así no lo exploten. Ten por seguro que pueden determinar que está ahí y lo explotarán. La seguridad mediante oscuridad no es seguridad en absoluto. Simplemente porque tengas un pequeño sitio, o un perfil relativamente bajo, no significa que un intruso no pueda estar interesado en lo que tienes. Discutiremos lo que estás protegiendo en las siguientes secciones. después. Organización de este Documento Este documento se ha dividido en secciones que cubren diversas cuestiones amplias de seguridad. La primera, Seguridad Física, abarca cómo necesitas proteger tu equipo físico de la intromisión. La segunda, Seguridad Local, describe cómo proteger tu sistema de intromisiones de los usuarios locales. La tercera, Seguridad de Ficheros y Sistemas de Ficheros, te enseña a configurar tus sistemas de ficheros y los permisos sobre tus ficheros. La siguiente, Seguridad de Contraseñas y Encriptación, discute cómo usar la encriptación para asegurar mejor tu equipo y tu red. Seguridad del núcleo discute las opciones de núcleo que debes configurar o tener en cuenta para tener un sistema seguro. Seguridad de la red, describe cómo asegurar mejor tu sistema Linux de ataques a la red. Preparación para la Seguridad, discute cómo preparar tu(s) equipo(s) antes de ponerlos en línea. Después, ¿Qué hacer durante y después de una Ruptura, discute qué hacer cuando detectas que está ocurriendo algo que compromete al sistema o detectas que ha ocurrido recientemente. En Recursos de Seguridad, se enumeran algunos recursos básicos de seguridad. La sección P y R Preguntas Frecuentemente Hechas, responde algunas preguntas frecuentemente realizadas y, finalmente, una sección de conclusión en Conclusión. Los dos principales puntos a tener presente cuando se lea este documento son: Sé consciente de tu sistema. Comprueba los logs de sistema tales como /var/log/messages y mantén el ojo sobre tu sistema. Mantén tu sistema puesto al día asegurándote de que has instalado las versiones actuales de software y has mejorado las alertas de seguridad. Sólo con hacer esto ayudarás a que tu sistema sea notablemente más seguro. Seguridad Física El primer escalón de seguridad que se necesita tener en cuenta es la seguridad física de tus sistemas de computadores. ¿Quién tiene acceso físico directo a tu equipo? ¿Debe tenerlo? ¿Puedes proteger tu equipo de su entrometimiento? ¿Debes hacerlo? Cuánta seguridad física necesitas en tu sistema depende mucho de tu situación y/o presupuesto. Si eres un usuario doméstico, probablemente no necesites mucha (aunque podrías necesitar proteger tu equipo de la intromisión de niños o parientes fastidiosos). Si estás en un laboratorio, necesitas considerablemente más, pero los usuarios aún necesitan poder obtener el trabajo hecho con las máquinas. Muchas de las siguientes secciones te ayudarán con esto. Si estás en una oficina, puedes o no necesitar asegurar tu máquina algunas horas o mientras estás fuera. En algunas empresas, dejar tu consola sin asegurar es causa de despido. Los métodos obvios de seguridad física tales como cierres de puertas, cables, cabinas cerradas y vigilancia por vídeo son todas buenas ideas, pero están más allá del alcance de este documento. :) Cierre del Computador Muchas carcasas de los modernos PCs incluyen una opción de "cierre". Normalmente será una cerradura en el frente de la carcasa que te permite girar la llave que trae a una posición abierta o cerrada. El cierre de la carcasa puede ayudar a impedir que alguien te robe tu PC, o que abra la carcasa y manipule/robe directamente tu hardware. A veces también impide que alguien reinicie tu computador con su propio diskette u otro hardware. Estos cierres de carcasa hacen cosas diferentes según el soporte en la placa base y de cómo esté construída la carcasa. En muchos PCs lo hacen de modo que hay que romper la carcasa para abrirla. En otros, lo hacen de modo que no te permite enchufar en ella nuevos teclados y ratones. Comprueba tu placa base o las instrucciones de la carcasa para más información. A veces esta puede ser una característica muy útil, aún cuando los cierres normalmente son de muy baja calidad y pueden ser vencidos fácilmente por atacantes con conocimientos de cerrajería. Algunas carcasas (más notablemente las de SPARC y mac) tienen una mochila por detrás que, si pones un cable alrededor, los atacantes tendrán que cortar el cable o romper la caja para entrar. El mero hecho de poner una cerradura o un cierre de combinación, puede ser un buen elemento disuasorio para alguien que intente robar tu equipo. Seguridad del BIOS El BIOS es el nivel más bajo de software que configura o manipula tu hardware para x86. LILO y otros métodos de inicio de Linux acceden al BIOS para determinar cómo iniciar tu equipo Linux. Otro hardware que se ejecuta en Linux tiene un software similar (OpenFirmware en Macs y los nuevos Suns, el inicio de Sun PROM, etc...). Puedes usar tu BIOS para impedir que los atacantes reinicien tu equipo y manipulen tu sistema Linux. Muchos BIOS de PC permiten poner una contraseña de inicio. Esto no proporciona mucha seguridad (el BIOS se puede reconfigurar, o quitarse, si alguien entra en la caja), pero podría ser un buen elemento disuasorio (esto es, lleva tiempo y deja huellas de la intrusión). De modo similar, en S/Linux (Linux para las máquinas procesadoras SPARC(mr)), tu EEPROM puede configurarse para pedir una contraseña de inicio. Esto podría tumbar a los atacantes torpes. Muchos BIOS de x86 también permiten especificar otras diversas configuraciones de seguridad buenas. Comprueba tu manual de BIOS o míralas la próxima vez que inicies. Por ejemplo, algunos BIOS no permiten iniciar desde unidades de discos floppy y algunos requieren contraseñas para acceder a algunas características del BIOS. Nota: Si tienes un equipo servidor y estableces una contraseña de inicio, tu equipo no se iniciará sin atención. Recuerda que necesitarás venir y entrar la contraseña en el caso de un fallo de energía. ;( Seguridad del cargador de Inicio Los distintos cargadores de inicio de Linux pueden tener también un juego de contraseña de inicio. LILO, por ejemplo, tiene password y restricted; password requiere siempre la contraseña en el momento del inicio, mientras que restricted requiere una contraseña para inicio sólo si se especifican algunas opciones (tales como single) en el indicador de LILO . Ten presente cuando establezcas todas estas contraseñas que necesitarás recordarlas. :) Recuerda también que estas contraseñas meramente retrasarán al atacante resuelto. No impedirán a alguien iniciar desde un floppy y montar tu partición de root. Si vas a usar seguridad junto con el cargador de inicio, podrías también desactivar el inicio desde un floppy en el BIOS de tu computador y proteger el BIOS con contraseña. Si alguien tiene información relacionada con la seguridad desde un cargador de inicio diferente, nos encantaría oirla. (grub, silo, milo, linload, etc). Nota: Si tienes un equipo servidor y estableces una contraseña de inicio, tu equipo no se iniciará sin atención. Recuerda que necesitaras venir y poner la contraseña en el caso de un fallo de corriente. ;( xlock y vlock Si te alejas de tu máquina de vez en cuando, es bueno poder "cerrar" tu consola para que nadie la asalte o mire tu trabajo. Dos programas que hacen esto son: xlock y vlock. xlock es un cierre X de presentación en pantalla. Debe estar incluido en todas las distribuciones de Linux que soporten X. Comprueba la página correspondiente del manual para más opciones, pero en general puedes ejecutar xlock desde cualquier terminal x de tu consola y se cerrará la pantalla, que requerirá tu contraseña para abrirse. vlock es un programita simple que te permite cerrar algunas o todas las consolas virtuales en tu sistema Linux. Puedes cerrar sólo aquella en la que estás trabajando o todas. Si sólo cierras una, otros pueden entrar y usar la consola; no podrán usar tu consola virtual hasta que la abras. vlock viene con Linux Redhat, pero tus resultados pueden ser diferentes. Cerrar la consola impedirá a alguien entrometerse en tu trabajo, pero desde luego no le impedirá reiniciar tu equipo o estropear de otro modo tu trabajo. Tampoco le impedirá acceder a tu equipo desde otra equipo en la red y causar problemas. Más importante, no impide a alguien desconectar completamente el Sistema X Window, ir al indicador de conexión de una consola virtual normal, o al VC desde el cual se arrancó el X11, suspenderlo y así obtener tus privilegios. Por esta razón, deberías considerar usarlo sólo bajo control de xdm. Detectar Compromisos de Seguridad Física La primera cosa a comprobar siempre es cuándo fue reiniciado tu equipo. Dado que Linux es un sistema operativo (SO) robusto y estable, las únicas veces que tu equipo debe reiniciarse es cuando tú lo desmontas para mejoras en el SO, recambios de hardware o cosas así. Si tu equipo ha sido reiniciado sin tú hacerlo, eso puede ser un signo de que un intruso lo ha puesto en peligro. Muchos de los modos en que tu equipo puede verse comprometido requieren que el intruso reinicie o apague el equipo. Comprueba los signos de intrusión en la carcasa y el área del computador. Aunque muchos intrusos limpian las huellas de su presencia de los logs, es una buena idea comprobarlos todos y anotar cualquier discrepancia. También es una buena idea almacenar los datos de log en un lugar seguro, tal como un servidor dedicado a log dentro de tu red bien protegida. Una vez que un equipo ha estado comprometido, los datos de log serán de poca utilidad porque lo más probable es que también hayan sido modificados por el intruso. El demonio syslog puede ser configurado para enviar automáticamente datos de log a un servidor central de syslog, pero normalmente se envían datos en texto plano, permitiendo a un intruso ver los datos cuando están siendo transferidos. Esto puede revelar información sobre tu red que no quieres que sea pública. Hay disponibles demonios syslog que encriptan los datos cuando se están enviando. Sé consciente también de que falsificar mensajes de syslog es fácil - con un programa de exploit que haya sido publicado. Syslog incluso acepta entradas de log de red que dicen venir del host local sin indicar su origen verdadero. Algunas cosas a comprobar en tus logs: Logs cortos o incompletos. Logs que contengan registros de fecha extraños. Logs con permisos o propietarios incorrectos. Registros de reinicios o de recomienzo de servicios. Logs perdidos. Entradas su o logins desde sitios extraños. Discutiremos los datos de log del sistema más adelante en este COMO. Seguridad Local La siguiente cosa a mirar es la seguridad de tu sistema contra los ataques procedentes de usuarios locales. ¿Dijimos usuarios locales? ¡Sí! Una de las primeras cosas que intentan los intrusos de un sistema como vía para explotar la cuenta de root es obtener acceso a una cuenta de usuario local. Con una seguridad local laxa, pueden entonces "mejorar" su acceso de usuario normal a acceso de root usando diversos bugs y servicios locales pobremente configurados. Si te aseguras de que tu seguridad local es adecuada, entonces el intruso tendrá que superar otro obstáculo. Los usuarios locales también pueden ocasionar un montón de estragos en tu sistema, incluso (especialmente) si son realmente quienes dicen que son. Proporcionar cuentas a gente que no conoces o de la que no tienes información de contacto es una idea muy mala. Crear Nuevas Cuentas Asegúrate de que provees cuentas de usuario sólo con los requerimientos minimos para la tarea que necesiten hacer. Si proporcionas a tu hijo (10 años) una cuenta, podrías querer que él sólo tenga acceso a un procesador de textos o un programa de dibujo, pero que le sea imposible borrar datos que no son suyos. Algunas buenas reglas empíricas sobre permitir a otra gente acceso legítimo a tu máquina Linux: Darles la cantidad mínima de privilegios que necesiten. Ser consciente de desde cuándo/dónde se conectan o se deberían estar conectando. Asegúrate de remover las cuentas inactivas. El uso del mismo ID de usuario en todos los computadores y redes es aconsejable para facilitar el mantenimiento del recuento, así como para permitir un análisis más fácil de los datos de log. La creación de ID de usuario de grupo debería estar absolutamente prohibida. Las cuentas de usuario también proporcionan transparencia y esto no es posible con cuentas de grupo. Muchas cuentas de usuario local que se usan en los compromisos de seguridad son las que no han sido usadas durante meses o años. Dado que nadie está usándolas, proporcionan el vehículo ideal de ataque. Seguridad del Root La cuenta más buscada en tu equipo es la cuenta de root (superusuario). Esta cuenta tiene autoridad sobre toda el equipo, lo cual puede incluir también autoridad sobre otros equipos en la red. Recuerda que sólo debes usar la cuenta de root para tareas muy cortas y específicas y que mayormente debes ejecutar programas como un usuario normal. Incluso los pequeños errores que cometas mientras estés conectado como root pueden causar problemas. Mientras menos tiempo estés conectado con privilegios de root, más seguro estarás. Varios trucos para evitar echar a perder como root tu propio equipo: Al realizar algún comando complejo, intenta ejecutarlo primero en modo no destructivo... especialmente los comandos que usen comodines: p.e., si quieres hacer "rm foo*.bak", primero haz "ls foo*.bak" y asegúrate que vas a borrar los archivos que piensas que vas a borrar. Usar echo en lugar de comandos destructivos también funciona a veces. Proporciona a tus usuarios un alias por defecto para que el comando rm les pida confirmación para el borrado de archivos. Conviértete en root sólo para hacer tareas simples y específicas. Si estás intentando planificar cómo hacer algo, vuelve al shell de usuario normal hasta que estés seguro de lo que necesita ser hecho por el root. El comando path es muy importante para el usuario root. El comando path (esto es, la variable de entorno PATH) especifica los directorios en los que el shell busca los programas. Procura limitar el comando path para el usuario root tanto como sea posible y nunca incluyas . (que significa "el directorio actual") en tu PATH. Además, nunca tengas directorios escribibles en tu path de búsqueda, dado que esto puede permitir a los atacantes modificar o poner nuevos binarios en tu path de búqueda, permitiéndoles ejecutar como root la próxima vez que ejecutes ese comando. Nunca uses como root el conjunto de herramientas rlogin/rsh/rexec (las llamadas utilidades-r). Están sujetas a muchos tipos de ataques y es absolutamente peligroso ejecutarlas como root. Nunca crees un archivo .rhosts para el root. El archivo /etc/securetty contiene una lista de terminales desde los que puede conectarse el root. Por defecto (con Linux Red Hat) esto se pone sólo para las consolas virtuales locales (vtys). Ten mucho cuidado al añadir cualquier otra cosa a este archivo. Tendrías que ser capaz de conectar remotamente como tu cuenta de usuario regular y entonces hacer su si lo necesitas (esperemos que sobre ssh u otro canal encriptado), así que no hay necesidad de conectar direcamente como root. Actúa despacio y de forma meditada cuando ejecutes programas como root. Tus acciones podrían afectar a un montón de cosas. ¡Piensa antes de teclear! Si irremediablemente necesitas permitir que alguien (mejor de mucha confianza) tenga acceso como root a tu máquina, hay algunas herramientas que te pueden ayudar. sudo permite a los usuarios usar su contraseña para acceder como root a un conjunto restringido de comandos. Esto te posibilitaría, por ejemplo, permitir que un usuario pueda extraer y montar medios removibles en tu sistema Linux, pero no tener otros privilegios de root. sudo también mantiene un log de todos los intentos sudo exitosos y fracasados, permitiéndote rastrear quién usó qué comando para hacer qué. Por esta razón sudo funciona bien incluso en lugares donde muchas personas tienen acceso de root, porque te ayuda a mantener un registro de los cambios realizados. Aunque sudo puede usarse para dar a usuarios específicos privilegios específicos para tareas específicas, tiene varios defectos. Debe usarse sólo para un conjunto limitado de tareas, como reiniciar un servidor o añadir nuevos usuarios. Cualquier programa que ofrece una salida al shell dará acceso de root a un usuario que lo pida vía sudo. Esto incluye a la mayoría de los editores, por ejemplo. También un programa tan inocuo como /bin/cat puede usarse para sobreescribir archivos, lo que podría permitir que el root fuese explotado. Considera sudo como un medio de contabilidad y no esperes que sustituya al usuario root y que encima sea seguro. Seguridad de ficheros y del sistema de ficheros Algunos minutos de preparación y planificación antes de poner tus sistemas online puede ayudar a protegerlos a ellos y a los datos almacenados en ellos. Nunca debe haber una excusa para que los usuarios ejecuten programas SUID/SGID desde sus directorios home. Usa la opción nosuid en /etc/fstab para particiones que sean escribibles por otros que no sean root. También puedes querer usar nodev y noexec sobre particiones home de usuarios, así como /var, prohibiendo de este modo la ejecución de programas y la creación de dispositivos de carácter o de bloque, que de todos modos nunca serían necesarios. Si estás exportando sistemas de ficheros usando NFS, asegúrate de configurar /etc/exports con el acceso más restrictivo posible. Esto significa no usar comodines, no permitir acceso de escritura de root y exportar ficheros de sólo-lectura siempre que sea posible. Configura tu umask de creación de archivos de usuarios para que sean tan restrictivos como sea posible. Ver configuraciones de umask. Si estás montando sistemas de ficheros usando un sistema de ficheros de red tal como NFS, asegúrate de configurar /etc/exports con restricciones adecuadas. Normalmente, es deseable usar `nodev', `nosuid' y, quizás, `noexec'. Poner límites al sistema de ficheros en vez de dejarlo ilimitado como viene por defecto. Puedes controlar los límites por usuario usando el módulo PAM de límites de recursos y /etc/pam.d/limits.conf. Por ejemplo, los límites para el grupo usuarios podrían parecerse a esto: · @users hard core 0· @users hard nproc 50· @users hard rss 5000 Esto significa prohibir la creación de ficheros core, restringir el número de procesos a 50 y restringir el uso de memoria por usuario a 5M. Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios en tu sistema. Debe mantenerse su integridad porque pueden usarse para determinar cuándo y desde dónde ha entrado un usuario (o un intruso potencial) en tu sistema. Estos ficheros también deben tener permisos 644 sin afectar a la operación normal del sistema. El bit inmutable puede usarse para impedir borrar o sobreescribir accidentalmente un fichero que debe ser protegido. También impide que alguien cree un enlace simbólico al fichero (tales enlaces simbólicos han sido la fuente de ataques incluyendo borrar /etc/passwd o /etc/shadow). Ver la página para chattr(1) del manual para información sobre el bit inmutable. Los ficheros SUID y SGID de tu sistema son un riesgo potencial de seguridad y deben ser manejados cuidadosamente. Dado que estos programas conceden privilegios especiales al usuario que está ejecutándolos, es necesario asegurarse de que no se instalen programas inseguros. Un truco favorito de los crackers es explotar programas SUID de root y dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso si el agujero original es tapado. Encuentra todos los programas SUID/SGID en tu sistema y mantén un registro de lo que son, para que seas consciente de cualesquiera cambios que te podrían indicar que hay un intruso potencial. Usa el comando siguiente para encontrar todos los programas SUID/SGID en tu sistema: root# find / -type f \( -perm -04000 -o -perm -02000 \) La distribución Debian ejecuta cada noche la tarea de determinar qué ficheros SUID existen. Luego compara esto a lo de las noches previas. Puedes verlo en /var/log/suid* para este log. Puedes quitar los permisos SUID o SGID a un programa sospechoso con chmod, después cambialo de nuevo si crees que es absolutamente necesario. Los ficheros escribibles por todo el mundo, particularmente los ficheros de sistema, pueden ser un agujero de seguridad si un cracker logra acceso a tu sistema y los modifica. Además, los directorios escribibles por todos son peligrosos, dado que permiten a un cracker añadir o borrar ficheros a su antojo. Para localizar todos los ficheros escribibles por todos en tu sistema, usa el siguiente comando: · root# find / -perm -2 ! -type l -ls y asegúrate de que sabes por qué esos ficheros son escribibles. En el curso normal de la operación, diversos ficheros serán escribibles por todos, incluyendo algunos desde /dev, y enlaces simbólicos, así el ! -type l que excluye a éstos del comando previo find. · Los ficheros sin propietario también pueden ser un indicio de que un intruso ha accedido a tu sistema. Puedes localizar en tu sistema los ficheros sin propietario, o que no pertenezcan a ningún grupo, con el comando: · root# find / -nouser -o -nogroup -print Encontrar ficheros .rhosts debería ser parte de tus deberes regulares de administración del sistema, puesto que estos ficheros no deben estar permitidos en tu sistema. Recuerda: un cracker sólo necesita una cuenta insegura para, potencialmente, lograr acceso a toda tu red. Puedes localizar todos los ficheros .rhosts en tu sistema con el siguiente comando: · root# find /home -name .rhosts -print · Finalmente, antes de cambiar los permisos sobre cualesquiera ficheros de sistema, asegúrate de que entiendes lo que estás haciendo. Nunca cambies los permisos sobre un fichero porque parezca el modo más fácil de lograr que las cosas funcionen. Determina siempre por qué el fichero tiene ese permiso antes de cambiarlo.
Configuraciones de Umask
El comando umask puede usarse para determinar el modo por defecto de creación de ficheros en tu sistema. Es el complemento octal del modo de fichero deseado. Si los ficheros se crean sin tomar en cuenta sus configuraciones de permisos, el usuario inadvertidamente podría dar permiso de lectura o escritura a alguien que no debería tener este permiso. Normalmente, las configuraciones de umask incluyen 022, 027 y 077 (que es el más restrictivo). Normalmente el umask se pone en /etc/profile, así se aplica a todos los usuarios en el sistema. La máscara de creación de archivos puede calcularse restando el valor deseado de 777. En otras palabras, un umask de 777 supondría que los ficheros nuevos creados no contendrían permiso de lectura, escritura o ejecución para nadie. Una máscara de 666 causaría que los ficheros nuevos creados tengan una máscara de 111. Por ejemplo, puedes tener una línea que se parezca a ésta: # Set the user's default umask umask 033
Asegúrate de poner el umask de root en 077, lo que discapacitará el permiso de lectura, escritura y ejecución para otros usuarios, a menos que se cambie explicitamente usando chmod. En este caso, los directorios recién creados tendrían permisos 744, obtenido restando 033 de 777. Los ficheros nuevos creados usando el umask 033 tendrían permisos de 644.
Si estás usando Red Hat, y te sumas a su esquema de creación de ID de usuario y de grupo (Grupos Privados de Usuario), sólo es necesario usar 002 para un umask. Esto es debido al hecho de que la configuración por defecto es de un usuario por grupo.
Permisos de Fichero
Es importante asegurar que tus ficheros de sistema no están abiertos a la edición casual por usuarios y grupos que no deberían estar realizando tal mantenimiento del sistema.
Unix separa el control de acceso sobre ficheros y directorios conforme a tres características: propietario, grupo y otro. Siempre hay exactamente un dueño, cualquier número de miembros del grupo y todos los otros.
Una rápida explicación de los permisos de Unix:
Dueño - Qué usuario(s) y grupo(s) mantiene(n) el control de las configuraciones de permisos del nodo y del padre del nodo.
Permisos - Los bits que pueden ser establecidos o reestablecidos para permitir ciertos tipos de acceso. Los permisos para directorios pueden tener un significado diferente al del mismo conjunto de permisos para ficheros.
Lectura:
Ser capaz de ver los contenidos de un fichero
Ser capaz de leer un directorio
Escritura:
Ser capaz de añadir o cambiar un fichero
Ser capaz de borrar o mover ficheros en un directorio
Ejecución:
Ser capaz de ejecutar un programa binario o un script de shell
Ser capaz de buscar en un directorio, combinado con permiso de lectura
Atributo de Salvar Texto: (Para directorios)
El "bit inmutable" tiene también un significado diferente cuando se aplica a directorios que cuando se aplica a ficheros. Si el bit inmutable se pone en un directorio, entonces el usuario sólo puede borrar los ficheros de los que es dueño o para los que tiene concedido un permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está diseñado para directorios como /tmp, que son escribibles por todos, pero donde puede no ser deseable permitir a cualquier usuario borrar ficheros a su gusto. El bit inmutable se ve como t en un listado largo de directorio.
Atributo SUID: (Para Ficheros)
Esto describe el conjunto de permisos de identidad de usuario sobre el fichero. Cuando el modo de acceso al conjunto de identidad de usuario se configura como permisos de propietario, y el fichero es ejecutable, a los procesos que se ejecutan bajo él se les concede acceso a los recursos del sistema basándose en el usuario dueño del fichero, como opuesto al usuario que ha creado el proceso. Esto es la causa de muchos exploits por "desbordamiento de búfer" ("buffer overflow").
Atribut SGID : (Para Ficheros)
Si se configura en los permisos de grupo, este bit controla la posición del "paquete de identidad de grupo" de un fichero. Actúa de la misma manera que el SUID, excepto en que es el grupo el afectado. El fichero debe ser ejecutable para que esto tenga algún efecto.
Atributo SGID: (Para directorios)
Si pones el bit SGID en un directorio (con chmod g+s directory), los ficheros creados en ese directorio tendrán su configuración de grupo para el grupo del directorio.
Tú - El dueño del fichero
Grupo - El grupo al que perteneces
Cualquiera - Cualquiera en el sistema que no es el propietario o un miembro del grupo
Ejemplos de Fichero: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directorio? (no) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (no) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (no) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(no)
Las siguientes líneas son ejemplos de los conjuntos mínimos de permisos que se requieren para realizar el acceso descrito. Si quieres puedes dar más permisos de los que están listados aquí, pues esto describe lo que hacen estos permisos mínimos sobre los ficheros: -r-------- Permite acceso de lectura al fichero por el dueño--w------- Permite al dueño modificar o borrar el fichero (Date cuenta que cualquiera con permiso de escritura en el directorio donde está el fichero puede sobreescribirlo y borrarlo)---x------ El dueño puede ejecutar ese programa, pero no scripts de shell, que requieren aún permiso de lectura---s------ Se ejecutará con ID Usuario = dueño efectivo --------s- Se ejecutará con ID Grupo = grupo efectivo-rw------T No pone al día "última fecha modificada". Normalmente se usa para ficheros swap---t------ Sin efecto. (anteriormente bit inmutable)
Ejemplo de Directorio: drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directorio? (sí, contiene muchos ficheros) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (sí, por kevin) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (sí, por usuarios) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(sí, cualquiera)
Las líneas que siguen son ejemplos de los conjuntos mínimos de permisos que se requieren para ejecutar el acceso descrito. Si quieres, puedes dar más permisos de los aquí listados, pues esto describe lo que hacen estos permisos mínimos sobre directorios: dr-------- Los contenidos pueden listarse, pero los atributos del fichero no pueden ser leídosd--x------ Se puede entrar en el directorio, y usarse en paths de ejecución completosdr-x------ Los atributos del fichero pueden leerse por el dueñod-wx------ Los ficheros pueden ser creados/borrados, incluso si el directorio no es el activod------x-t Impide el borrado de ficheros por otros con acceso de escritura. Se usa en /tmpd---s--s-- Sin efecto
Los ficheros de configuración del sistema (normalmente en /etc) están usualmente en modo 640 (-rw-r-----) y el dueño es el root. Dependiendo de los requisitos de seguridad de tu sitio, puedes ajustar esto. Nunca dejes los ficheros de sistema escribibles por un grupo o por cualquiera. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deben ser legibles por el root y los directorios en /etc al menos no deben ser accesibles a otros.
Scripts de Shell SUID
Los scripts de shell SUID son un riesgo importante de seguridad y por esta razón el núcleo no les hace honores. Con independencia de lo seguro que tú consideres que es el script de shell, puede ser explotado para dar al cracker un shell de root.
Comprobar la Integridad con Tripwire Tripwire
Otra manera muy buena de detectar ataques locales sobre tu sistema (y también a la red) es correr un chequeador de integridad como Tripwire. Tripwire ejecuta varias comprobaciones tipo checksum en todos tus ficheros binarios y de configuración importantes y los compara contra una base de datos previa de valores de referencia bien conocidos. De este modo, todos los cambios en los ficheros se notarán.
Es una buena idea instalar Tripwire en un floppy y después ponerle físicamente la protección contra escritura en el floppy. De este modo, los intrusos no podrán entrometerse con el mismo Tripwire ni cambiar la base de datos. Una vez que tengas configurado Tripwire, es una buena idea ejecutarlo como parte de tus deberes normales de administración de seguridad para ver si algo ha cambiado.
Puedes incluso añadir una entrada crontab para ejecutar Tripwire desde tu floppy todas las noches y mandarte un "emilio" con los resultados por la mañana. Algo como: # set mailto MAILTO=kevin # run Tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire
te enviará por correo-e un informe cada mañana a las 5:15am.
Tripwire puede ser una bendición para detectar intrusos antes de que los notes de otro modo. Dado que cambian un montón de ficheros en el resultado del sistema, tienes que tener cuidado con lo que es la actividad del cracker y lo que es tu propia actividad.
Encontrarás grátis Tripwire en http://www.tripwiresecurity.com/. Los manuales y el soporte pueden comprarse.
Caballos Troyanos
Los "Caballos Troyanos" se denominan así por la artimaña que se cuenta en la "Iliada" de Homero. La idea es que un cracker distribuye un programa o binario que suena estupendo, y anima a otra gente a descargarlo y a ejecutarlo como root. Entonces el programa puede comprometer su sistema y ellos no se dan cuenta. Mientras piensan que el binario que acaban de bajarse hace una cosa (y muy bien podría hacerla), también compromete su seguridad.
Debes tener cuidado con qué programas instalas en tu máquina. Redhat proporciona comrpobaciones checksum MD5 y firmas PGP en sus ficheros RPM para que puedas verificar que estás instalando la cosa real. Otras distribuciones tienen similares métodos. ¡Nunca debes ejecutar como root cualquier binario desconocido, para el cual no tienes la fuente! Pocos atacantes quieren liberar el código fuente para escrutinio público.
Aunque puede ser complejo, asegúrate que obtienes la fuente de un programa desde su sitio de distribución auténtico. Si el programa se va a ejecutar como root, asegúrate de que o bien tú o bien alguien en quien confías ha mirado la fuente y la ha verificado.
Asegúrate de poner el umask de root en 077, lo que discapacitará el permiso de lectura, escritura y ejecución para otros usuarios, a menos que se cambie explicitamente usando chmod. En este caso, los directorios recién creados tendrían permisos 744, obtenido restando 033 de 777. Los ficheros nuevos creados usando el umask 033 tendrían permisos de 644.
Si estás usando Red Hat, y te sumas a su esquema de creación de ID de usuario y de grupo (Grupos Privados de Usuario), sólo es necesario usar 002 para un umask. Esto es debido al hecho de que la configuración por defecto es de un usuario por grupo.
Permisos de Fichero
Es importante asegurar que tus ficheros de sistema no están abiertos a la edición casual por usuarios y grupos que no deberían estar realizando tal mantenimiento del sistema.
Unix separa el control de acceso sobre ficheros y directorios conforme a tres características: propietario, grupo y otro. Siempre hay exactamente un dueño, cualquier número de miembros del grupo y todos los otros.
Una rápida explicación de los permisos de Unix:
Dueño - Qué usuario(s) y grupo(s) mantiene(n) el control de las configuraciones de permisos del nodo y del padre del nodo.
Permisos - Los bits que pueden ser establecidos o reestablecidos para permitir ciertos tipos de acceso. Los permisos para directorios pueden tener un significado diferente al del mismo conjunto de permisos para ficheros.
Lectura:
Ser capaz de ver los contenidos de un fichero
Ser capaz de leer un directorio
Escritura:
Ser capaz de añadir o cambiar un fichero
Ser capaz de borrar o mover ficheros en un directorio
Ejecución:
Ser capaz de ejecutar un programa binario o un script de shell
Ser capaz de buscar en un directorio, combinado con permiso de lectura
Atributo de Salvar Texto: (Para directorios)
El "bit inmutable" tiene también un significado diferente cuando se aplica a directorios que cuando se aplica a ficheros. Si el bit inmutable se pone en un directorio, entonces el usuario sólo puede borrar los ficheros de los que es dueño o para los que tiene concedido un permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está diseñado para directorios como /tmp, que son escribibles por todos, pero donde puede no ser deseable permitir a cualquier usuario borrar ficheros a su gusto. El bit inmutable se ve como t en un listado largo de directorio.
Atributo SUID: (Para Ficheros)
Esto describe el conjunto de permisos de identidad de usuario sobre el fichero. Cuando el modo de acceso al conjunto de identidad de usuario se configura como permisos de propietario, y el fichero es ejecutable, a los procesos que se ejecutan bajo él se les concede acceso a los recursos del sistema basándose en el usuario dueño del fichero, como opuesto al usuario que ha creado el proceso. Esto es la causa de muchos exploits por "desbordamiento de búfer" ("buffer overflow").
Atribut SGID : (Para Ficheros)
Si se configura en los permisos de grupo, este bit controla la posición del "paquete de identidad de grupo" de un fichero. Actúa de la misma manera que el SUID, excepto en que es el grupo el afectado. El fichero debe ser ejecutable para que esto tenga algún efecto.
Atributo SGID: (Para directorios)
Si pones el bit SGID en un directorio (con chmod g+s directory), los ficheros creados en ese directorio tendrán su configuración de grupo para el grupo del directorio.
Tú - El dueño del fichero
Grupo - El grupo al que perteneces
Cualquiera - Cualquiera en el sistema que no es el propietario o un miembro del grupo
Ejemplos de Fichero: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directorio? (no) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (no) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (no) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(no)
Las siguientes líneas son ejemplos de los conjuntos mínimos de permisos que se requieren para realizar el acceso descrito. Si quieres puedes dar más permisos de los que están listados aquí, pues esto describe lo que hacen estos permisos mínimos sobre los ficheros: -r-------- Permite acceso de lectura al fichero por el dueño--w------- Permite al dueño modificar o borrar el fichero (Date cuenta que cualquiera con permiso de escritura en el directorio donde está el fichero puede sobreescribirlo y borrarlo)---x------ El dueño puede ejecutar ese programa, pero no scripts de shell, que requieren aún permiso de lectura---s------ Se ejecutará con ID Usuario = dueño efectivo --------s- Se ejecutará con ID Grupo = grupo efectivo-rw------T No pone al día "última fecha modificada". Normalmente se usa para ficheros swap---t------ Sin efecto. (anteriormente bit inmutable)
Ejemplo de Directorio: drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directorio? (sí, contiene muchos ficheros) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (sí, por kevin) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (sí, por usuarios) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(sí, cualquiera)
Las líneas que siguen son ejemplos de los conjuntos mínimos de permisos que se requieren para ejecutar el acceso descrito. Si quieres, puedes dar más permisos de los aquí listados, pues esto describe lo que hacen estos permisos mínimos sobre directorios: dr-------- Los contenidos pueden listarse, pero los atributos del fichero no pueden ser leídosd--x------ Se puede entrar en el directorio, y usarse en paths de ejecución completosdr-x------ Los atributos del fichero pueden leerse por el dueñod-wx------ Los ficheros pueden ser creados/borrados, incluso si el directorio no es el activod------x-t Impide el borrado de ficheros por otros con acceso de escritura. Se usa en /tmpd---s--s-- Sin efecto
Los ficheros de configuración del sistema (normalmente en /etc) están usualmente en modo 640 (-rw-r-----) y el dueño es el root. Dependiendo de los requisitos de seguridad de tu sitio, puedes ajustar esto. Nunca dejes los ficheros de sistema escribibles por un grupo o por cualquiera. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deben ser legibles por el root y los directorios en /etc al menos no deben ser accesibles a otros.
Scripts de Shell SUID
Los scripts de shell SUID son un riesgo importante de seguridad y por esta razón el núcleo no les hace honores. Con independencia de lo seguro que tú consideres que es el script de shell, puede ser explotado para dar al cracker un shell de root.
Comprobar la Integridad con Tripwire Tripwire
Otra manera muy buena de detectar ataques locales sobre tu sistema (y también a la red) es correr un chequeador de integridad como Tripwire. Tripwire ejecuta varias comprobaciones tipo checksum en todos tus ficheros binarios y de configuración importantes y los compara contra una base de datos previa de valores de referencia bien conocidos. De este modo, todos los cambios en los ficheros se notarán.
Es una buena idea instalar Tripwire en un floppy y después ponerle físicamente la protección contra escritura en el floppy. De este modo, los intrusos no podrán entrometerse con el mismo Tripwire ni cambiar la base de datos. Una vez que tengas configurado Tripwire, es una buena idea ejecutarlo como parte de tus deberes normales de administración de seguridad para ver si algo ha cambiado.
Puedes incluso añadir una entrada crontab para ejecutar Tripwire desde tu floppy todas las noches y mandarte un "emilio" con los resultados por la mañana. Algo como: # set mailto MAILTO=kevin # run Tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire
te enviará por correo-e un informe cada mañana a las 5:15am.
Tripwire puede ser una bendición para detectar intrusos antes de que los notes de otro modo. Dado que cambian un montón de ficheros en el resultado del sistema, tienes que tener cuidado con lo que es la actividad del cracker y lo que es tu propia actividad.
Encontrarás grátis Tripwire en http://www.tripwiresecurity.com/. Los manuales y el soporte pueden comprarse.
Caballos Troyanos
Los "Caballos Troyanos" se denominan así por la artimaña que se cuenta en la "Iliada" de Homero. La idea es que un cracker distribuye un programa o binario que suena estupendo, y anima a otra gente a descargarlo y a ejecutarlo como root. Entonces el programa puede comprometer su sistema y ellos no se dan cuenta. Mientras piensan que el binario que acaban de bajarse hace una cosa (y muy bien podría hacerla), también compromete su seguridad.
Debes tener cuidado con qué programas instalas en tu máquina. Redhat proporciona comrpobaciones checksum MD5 y firmas PGP en sus ficheros RPM para que puedas verificar que estás instalando la cosa real. Otras distribuciones tienen similares métodos. ¡Nunca debes ejecutar como root cualquier binario desconocido, para el cual no tienes la fuente! Pocos atacantes quieren liberar el código fuente para escrutinio público.
Aunque puede ser complejo, asegúrate que obtienes la fuente de un programa desde su sitio de distribución auténtico. Si el programa se va a ejecutar como root, asegúrate de que o bien tú o bien alguien en quien confías ha mirado la fuente y la ha verificado.
Seguridad de Contraseña y Encriptación
Uno de los rasgos de seguridad más importantes usados hoy son las contraseñas. Tanto para tí como para tus usuarios es importante tener contraseñas seguras y no fácilmente averiguables. La mayoría de las distribuciones de Linux más recientes incluyen programas passwd que no te permiten poner una contraseña fácilmente averiguable. Asegúrate de que tu programa passwd está actualizado y tiene esos atributos.
Está más allá del alcance de este documento una discusión profunda sobre encriptación, pero una introducción viene bien. La encriptación es muy útil, posiblemente incluso necesaria en este momento y época. Hay todo tipo de métodos de encriptar datos, cada uno con su propio conjunto de características.
La mayoría de los Unices (y Linux no es una excepción) usan principalmente un algoritmo de encriptación de una sola vía, llamado DES (Data Encryption Standard), para encriptar tus contraseñas. Esta contraseña encriptada se almacena entonces (normalmente) en /etc/passwd o (menos común) en /etc/shadow. Cuando intentas conectar, la contraseña que introduces se encripta de nuevo y se compara con la que se entró en el fichero que almacena tus contraseñas. Si casan, debe ser la misma contraseña y se te permite el acceso. Aunque DES es un algoritmo de encriptación de doble vía (puedes codificar y luego descodificar un mensaje, dadas las claves correctas), la variante que la mayoría de los Unices usan es de una vía. Esto quiere decir que no es posible revertir la encriptación para obtener la contraseña a partir de los contenidos de /etc/passwd (o /etc/shadow).
Los ataques de fuerza bruta, tales como "Crack" o "John the Ripper" (ver la Sección crack ) a menudo pueden averiguar las contraseñas, a menos que tu contraseña sea lo suficientemente aleatoria. Los módulos PAM (ver abajo) te permiten usar una rutina de encriptación diferente con tus contraseñas (MD5 o parecidos). También puedes usar Crack en tu provecho. Considera el ejecutar periódicamente Crack contra tu base de datos de contraseñas, para encontrar contraseñas inseguras. Contacta entonces con el usuario afectado e instrúyelo para que cambie su contraseña.
Puedes ir a http://consult.cern.ch/writeup/security/security_3.html para más información sobre cómo elegir una buena contraseña.
Criptografía PGP y de Clave-Pública
La criptografía de clave pública, tal como la que usa PGP, usa una clave para encriptación y una clave para desencriptación. La criptografía tradicional, sin embargo, usa la misma clave para encriptación y desencriptación; esta clave debe ser conocida por las dos partes y ser transferida de alguna forma desde una a la otra con seguridad.
Para aliviar la necesidad de transmitir con seguridad la clave de encriptación, la encriptación de clave pública usa dos claves separadas: una clave pública y una clave privada. La clave pública de cada persona está disponible para que cualquiera haga la encriptación, mientras que, al mismo tiempo, cada persona mantiene su clave privada para descifrar los mensajes encriptados con la clave pública correcta.
Hay ventajas tanto en la criptografía de clave pública y de clave privada y se puede leer sobre sus diferencias en el RSA Cryptography FAQ, listado al final de esta sección.
PGP (Pretty Good Privacy) está bien soportado en Linux. Las versiones 2.6.2 y 5.0 se sabe que funcionan bien. Para una buena instrucción sobre PGP y cómo usarlo, echa un vistazo al FAQ de PGP: http://www.pgp.com/service/export/faq/55faq.cgi
Asegúrate de usar la versión que es aplicable en tu país. Debido a las restricciones a la exportación por parte del Gobierno de los USA, está prohibido que la encriptación fuerte sea transferida de forma electrónica fuera del país.
Los controles de USA sobre la exportación se rigen ahora por EAR (Export Administration Regulations). Ya no se gobiernan por ITAR.
Hay también una guía paso a paso para configurar PGP en Linux disponible en http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html. Fue escrita para la versión internacional de PGP, pero es adaptable fácilmente a la versión de los Estados Unidos. También puedes necesitar un patch para algunas de las últimas versiones de Linux; el patch está disponible en ftp://metalab.unc.edu/pub/Linux/apps/crypto.
Hay funcionando un proyecto sobre una re-implementación libre de pgp con fuente abierta. GnuPG es un sustituto completo y grátis de PGP. Porque no usa IDEA ni RSA puede usarse sin restricciones. GnuPG está casi de acuerdo con RFC2440 (OpenPGP). Ver la página web GNU Privacy Guard para más información: http://www.gpg.org/.
Más información sobre criptografía puede encontrarse en el FAQ de criptografía de RSA, disponible en http://www.rsa.com/rsalabs/newfaq/. Aquí encontrarás información sobre términos tales como "Diffie-Hellman", "criptografía de clave pública", "certificados digitales", etc.
SSL, S-HTTP, HTTPS y S/MIME
Con frecuencia los usuarios preguntan sobre las diferencias entre los diversos protocolos de seguridad y encriptación y sobre cómo usarlos. Aunque éste no es un documento sobre encriptación, es una buena idea explicar brevemente lo que es cada protocolo y dónde encontrar más información.
SSL: - SSL, o Secure Sockets Layer, es un método de encriptación desarrollado por Netscape para proveer de seguridad en Internet. Soporta diversos protocolos de encriptación diferentes y proporciona autentificación de cliente y servidor. SSL opera en el nivel de transporte, crea un canal seguro de datos encriptados, y así puede encriptar sin costuras datos de muchos tipos. Esto se ve más fácilmente cuando se va a un sitio seguro para ver un documento online seguro con Communicator, y sirve de base para comunicaciones seguras con Communicator, así como para muchas otras Comunicaciones de Netscape con encriptación de datos. Más información puede encontrarse en http://www.consensus.com/security/ssl-talk-faq.html. Hay información sobre otras implementaciones de seguridad de Netscape, y un buen punto de partida para estos protocolos, disponible en http://home.netscape.com/info/security-doc.html.
S-HTTP: - S-HTTP es otro protocolo que proporciona servicios de seguridad en Internet. Fue diseñado para proporcionar confidencialidad, autentificación, integridad y no repudiabilidad no puede confundirse con ningún otro], al tiempo que para soportar mecanismos de gestión de claves múltiples y algoritmos criptográficos mediante la negociación opcional entre las partes implicadas en cada transacción. S-HTTP está limitado al software específico que lo implementa, y encripta cada mensaje individualmente. [Del FAQ de Criptografía de RSA, página 138].
S/MIME: - S/MIME, o Secure Multipurpose Internet Mail Extension, es un estándar de encriptación usado para encriptar correo electrónico y otros tipos de mensajes en Internet. Es un estándar abierto desarrollado por RSA, así que es probable que lo veamos en Linux un día de estos. Más información sobre S/MIME puede encontrarse en http://home.netscape.com/assist/security/smime/overview.html.
Implementaciones IPSEC para Linux
Junto a CIPE y otras formas de encriptación de datos, hay también diversas otras implementaciones de IPSEC para Linux. IPSEC es un esfuerzo de la IETF para crear comunicaciones criptográficamente seguras a nivel de red IP y para proporcionar autentificación, integridad, control de acceso y confidencialidad. Información sobre IPSEC e Internet puede encontrarse en http://www.ietf.org/html.charters/ipsec-charter.html. También puedes encontrar enlaces a otros protocolos que implican gestión de claves, una lista de correo sobre IPSEC y ficheros.
La implementación del x-kernel de Linux, que se está desarrollando en la Universidad de Arizona, usa un entorno basado en el objeto para implementar protocolos de red llamados x-kernel y puede encontrarse en http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html. Dicho más sencillo, el x-kernel es un método de pasar mensajes a nivel de núcleo, lo que contribuye a una implementación más fácil.
Otra implementación IPSEC de libre disposición es el FreeS/WAN IPSEC de Linux. Su página web afirma,
"Estos servicios te permiten construir túneles seguros a través de redes inseguras. Todo lo que pasa a través de la red insegura es encriptado por la máquina pasarela IPSEC y desencriptado por la pasarela en el otro extremo. El resultado es la Red Privada Virtual (Virtual Private Network) o VPN. Esta es una red que es efectivamente privada, aún cuando incluye equipos en diversos sitios diferentes conectados mediante la insegura Internet."
Está disponible para descargar en http://www.xs4all.nl/~freeswan/ y ha alcanzado ya la 1.0 en el momento de escribir esto.
Al igual que otras formas de criptografía, no se distribuye por defecto con el núcleo debido a restrictiones a la exportación.
ssh (Shell Seguro) y stelnet
ssh y stelnet son programas que te permiten conectarte a sistemas remotos y tener una conexión encriptada.
ssh es un paquete de programas usados como un sustituto seguro para rlogin, rsh y rcp. Usa la criptografía de clave pública para encriptar comunicaciones entre dos hosts, asi como para autentificar usuarios. Puede usarse para conectar de forma segura a un host remoto o copiar datos entre hosts, al tiempo que se impiden los ataques hombre-en-medio (sesión hijacking) y el engaño de DNS. Realizará una compresión de datos en tus conexiones y comunicaciones X11 seguras entre hosts. La página principal de ssh puede encontrarse en http://www.cs.hut.fi/ssh/
También puedes usar ssh desde tu estación de trabajo Windows a tu servidor Linux ssh. Hay varias implementaciones de cliente de Windows libremente disponibles, incluyendo la que está en http://guardian.htu.tuwien.ac.at/therapy/ssh/ así como la implementación comercial de DataFellows, en http://www.datafellows.com/. Hay también un proyecto de fuente abierta para re-implementar ssh llamado "psst...". Para más información ver: http://www.net.lut.ac.uk/psst/
SSLeay es una implementación libre del protocolo Secure Sockets Layer de Netscape, desarrollado por Eric Young. Incluye diversas aplicaciones, tales como Secure para telnet, un módulo para Apache, diversas bases de datos y diversos algoritmos incluyendo DES, IDEA y Blowfish.
Usando esta librería se crea una sustitución segura de telnet que realiza la encriptación sobre una conexión telnet. A diferencia de SSH, stelnet usa SSL, el protocolo Secure Sockets Layer desarrollado por Netscape. Puedes encontrar Telnet Seguro y FTP Seguro, comenzando por el FAQ SSLeay, disponible en http://www.psy.uq.oz.au/~ftp/Crypto/.
SRP es otra implementación segura de telnet/ftp. De su página web:
"El proyecto SRP está desarrollando software de Internet seguro para uso libre en todo el mundo. Comenzando con una distribución de Telnet y FTP completamente segura, esperamos reemplazar los débiles sistemas de autentification en redes con sustitutos fuertes que no sacrifican la seguridad por la amigabilidad hacia el usuario. ¡La seguridad debe estar por defecto, no ser una opción!"
Para más información, ir a http://srp.stanford.edu/srp.
PAM - Módulos de Autentificación Enfuchables
Las versiones más recientes de la distribución Red Hat de Linux vienen con un esquema unificado de autentificación llamado "PAM". PAM te permite cambiar tus métodos y requisitos de autentificación al vuelo y encapsular todos los métodos de autentificación local sin recompilar ninguno de tus binarios. La configuración de PAM está más allá del alcance de este documento, pero no dejes de echar una ojeada al sitio web de PAM para más información. http://www.kernel.org/pub/linux/libs/pam/index.html.
Sólo unas pocas de las cosas que puedes hacer con PAM:
Usar otra encriptación distinta a DES para tus contraseñas. (Haciéndolas más difíciles a la decodificación por fuerza bruta)
Establecer límites de recursos sobre todos tus usuarios para que no puedan realizar ataques de negación-de-servicio (número de procesos, cantidad de memoria, etc)
Activar contraseñas sombra (ver debajo) al vuelo
Permitir a usuarios específicos conectar sólo en momentos específicos desde sitios específicos
Dedicar unas pocas horas a instalar y configurar tu sistema, puede impedir muchos ataques incluso antes de que ocurran. Por ejemplo, usa PAM para desactivar el uso por todo el sistema de ficheros .rhosts en los directorios home del usuario, añadiendo estas líneas a /etc/pam.d/rlogin: # # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts
Encapsulación IP Criptográfica (CIPE)
El objetivo primero de este software es proporcionar una facilidad para la interconexión segura de subredes (contra indiscreciones, incluyendo el análisis de tráfico y la inyección de mensaje falsificado) a lo largo de una red insegura de paquetes tal como es Internet.
CIPE encripta los datos a nivel de red. Los paquetes que viajan entre hosts por la red están encriptados. El motor de encriptación se sitúa cerca del controlador que envía y recibe los paquetes.
Esto es distinto a SSH, que encripta los datos mediante conexión, al nivel de socket. Se encripta una conexión lógica entre programas que se ejecutan en diferentes hosts.
CIPE puede usarse para hacer túneles, con el fin de crear una Red Privada Virtual (VPN). La encriptación de nivel bajo tiene la ventaja de que puede hacerse funcionar de forma transparente entre las dos redes conectadas en la VPN, sin ningún cambio en el software de aplicación.
Resumido de la documentación de CIPE:
Los estándares IPSEC definen un conjunto de protocolos que pueden ser usados (entre otras cosas) para construir VPNs encriptadas. Sin embargo, IPSEC es más bien un conjunto de protocolos de peso pesado y complicado con un montón de opciones, las implementaciones del conjunto completo de protocolos se usan aún raramente y algunos problemas (tales como gestión de claves) no están todavía completamente resueltos. CIPE usa un enfoque más simple, en el cual muchas cosas que pueden ser parametrizadas (tal como la elección del algoritmo de encriptación real usado) son una elección que se fija en el momento de la instalación. Esto limita la flexibilidad, pero permite una implementación simple (y por tanto eficiente, fácil de depurar...).
Más información puede encontrarse en http://www.inka.de/~bigred/devel/cipe.html
Al igual que otras formas de criptografía, no es distribuída con el núcleo por defecto debido a restricciones a la exportación.
Kerberos
Kerberos es un sistema de autentificación desarrollado por el Proyecto Athena en el MIT. Cuando un usuario se conecta, Kerberos autentifica a este usuario (usando una contraseña) y proporciona al usuario una forma de probar su identidad a otros servidores y hosts esparcidos por toda de la red.
Después, esta autentificación se usa por programas como rlogin para permitir al usuario conectar con otros hosts sin una contraseña (en lugar del fichero .rhosts). Este método de autentificación también puede usarse por el sistema de correo para garantizar que el correo se entrega a la persona correcta, así como para garantizar que el remitente es quien dice ser.
Kerberos y los otros programas que vienen con él, impide a los usuarios "engañar" al sistema haciéndole creer que son otros distintos. Desafortunadamente, instalar Kerberos es muy intrusivo, al requerir la modificación o sustitución de numerosos programas estándar.
Puedes encontrar más información sobre kerberos mirando en el kerberos FAQ y el código puede encontrarse en http://nii.isi.edu/info/kerberos/.
[De: Stein, Jennifer G., Clifford Neuman, y Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]
Kerberos no debería ser tu primer paso para mejorar la seguridad de tu host. Es bastante embrollado y no se usa tan ampliamente como, digamos, SSH.
Contraseñas Sombra.
Las contraseñas sombra son un medio de mantener secreta, para los usuarios normales, la información de tu contraseña cifrada. Normalmente, estas contraseñas encriptadas se almacenan en el fichero /etc/passwd de lectura para todos. Cualquiera puede ejecutar sobre ellas programas que averiguan contraseñas e intentar determinar lo que son. Las contraseñas sombra, por el contrario, se archivan en /etc/shadow, que sólo pueden leer los usuarios privilegiados. Para usar contraseñas sombra, necesitas asegurarte de que todas tus utilidades que necesiten acceso a la información de la contraseña sean recompiladas para soportarlas. PAM (ver más arriba) también te permite sólo enchufar un módulo de sombra; no requiere la re-compilación de los ejecutables. Puedes acudir al Contraseña-Sombra COMO para información adicional si es necesario. Está disponible en http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html Su fecha es más bien reciente y no se necesita en las distribuciones que soporten PAM.
"Crack" y "John the Ripper"
Si por alguna razón tu programa passwd no impone contraseñas difíciles de averiguar, podrías querer ejecutar un programa rompedor de contraseñas y asegurarte de que las contraseñas de tus usuarios son seguras.
Los programas rompedores de contraseñas operan sobre una idea simple: prueban cada palabra del diccionario, y después las variaciones de estas palabras, encriptando cada una y comprobándola frente a tu contraseña encriptada. Si obtienen una que case, saben cuál es tu contraseña.
Hay muchos programas por ahí... los dos más notables son "Crack" y "John the Ripper" ( http://www.false.com/security/john/index.html). Te llevarán un montón de tiempo de cpu, pero solo sabrás si un atacante podría lograr usarlas si las ejecutas tú mismo primero y notificas a los usuarios con contraseñas débiles. Ten en cuenta que un atacante tendría que usar primero algún otro agujero para leer tu fichero /etc/passwd, pero tales agujeros son más comúnes de lo que podrías pensar.
Dado que la seguridad es sólo tan fuerte como el host más inseguro, vale la pena mencionar que si tienes algunos equipos Windows en tu red, deberías probar L0phtCrack, un programa de Crack para Windows. Está disponible en http://www.l0pht.com/
CFS - Sistema de Fichero Criptográfico y TCFS - Sistema de Fichero Criptográfico Transparente
CFS es una forma de encriptar árboles de directorios completos y permitir a los usuarios almacenar en ellos ficheros encriptados. Usa un servidor NFS que se ejecuta sobre una máquina local. Los RPMS están disponibles en http://www.replay.com/redhat/ y más información sobre cómo funcionan está en ftp://ftp.research.att.com/dist/mab/.
TCFS mejora a CFS añadiendo más integración con el sistema de ficheros, de modo que el sistema de ficheros que está encriptado es transparente para los usuarios. Más información en: http://edu-gw.dia.unisa.it/tcfs/.
Tampoco necesita usarse con sistemas de achivos completos. Funciona en árboles de directorios también.
X11, SVGA y seguridad de pantalla
X11
Es importante que asegures tu pantalla gráfica para impedir que los atacantes se apropien de tus contraseñas cuando las escribas, puedan leer los documentos o la información que estás leyendo en pantalla o, incluso, usar un agujero para lograr acceso de root. Ejecutar las aplicaciones X remotas sobre una red también puede ser peligroso, permitiendo a los reastreadores ver toda tu interacción con el sistema remoto.
X tiene varios mecanismos de control de acceso. El más simple de ellos está basado en el host: usas xhost para especificar a qué hosts se les permite acceder a tu pantalla. Esto no es seguro en absoluto, porque si alguien tiene acceso a tu máquina, puede hacer xhost + su máquina y obtenerlo fácilmente. Igualmente, si tienes que conceder acceso desde una máquina que no es de confianza, desde ahí cualquiera puede comprometer tu pantalla.
Cuando se usa xdm (Gestor X de Pantalla) para conectar, se obtiene un método de acceso mucho mejor: MIT-MAGIC-COOKIE-1. Se genera una "cookie" de 128-bit y se almacena en tu fichero .Xauthority. Si necesitas conceder acceso a tu pantalla a una máquina remota, puedes usar el comando xauth y la información en tu fichero .Xauthority para proporcionar acceso sólo a esa conexión. Ver el mini-cómo de Remote-X-Apps, disponible en http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.
Puedes usar también ssh (ver ssh , arriba) para permitir conexiones X seguras. Esto tiene la ventaja de que también es transparente para el usuario final y significa que ningún dato no encriptado fluye a lo largo de la red.
Echa un vistazo a la página Xsecurity del manual para más información sobre seguridad X. La apuesta más segura es usar xdm para conectar tu consola y luego usar ssh para ir a sitios remotos sobre los que puedes ejecutar programas X.
SVGA
Los programas SVGAlib normalmente son SUID-root para acceder a todo el hardware de vídeo de tu Linux. Esto los hace muy peligrosos. Si fallan, lo normal es que necesites reiniciar tu equipo para tener de nuevo una consola usable. Asegúrate de que cualesquiera programas SVGA que ejecutes sean auténticos y pueda al menos haber algo de confianza. Aún mejor, no ejecutes ninguno para nada.
GGI (Proyecto de Interface Gráfico Genérico)
El proyecto GGI de Linux está intentando solucionar diversos problemas con los interfaces de vídeo en Linux. GGI cambiará una pequeña parte del código de vídeo en el núcleo de Linux y así controlará el acceso al sistema de vídeo. Esto significa que GGI será capaz en cualquier momento de restaurar en tu consola un estado deseable conocido. También permitirá una clave de atención segura, para que puedas estar seguro de que no hay ningún programa troyano de login ejecutándose en tu consola. http://synergy.caltech.edu/~ggi/
Está más allá del alcance de este documento una discusión profunda sobre encriptación, pero una introducción viene bien. La encriptación es muy útil, posiblemente incluso necesaria en este momento y época. Hay todo tipo de métodos de encriptar datos, cada uno con su propio conjunto de características.
La mayoría de los Unices (y Linux no es una excepción) usan principalmente un algoritmo de encriptación de una sola vía, llamado DES (Data Encryption Standard), para encriptar tus contraseñas. Esta contraseña encriptada se almacena entonces (normalmente) en /etc/passwd o (menos común) en /etc/shadow. Cuando intentas conectar, la contraseña que introduces se encripta de nuevo y se compara con la que se entró en el fichero que almacena tus contraseñas. Si casan, debe ser la misma contraseña y se te permite el acceso. Aunque DES es un algoritmo de encriptación de doble vía (puedes codificar y luego descodificar un mensaje, dadas las claves correctas), la variante que la mayoría de los Unices usan es de una vía. Esto quiere decir que no es posible revertir la encriptación para obtener la contraseña a partir de los contenidos de /etc/passwd (o /etc/shadow).
Los ataques de fuerza bruta, tales como "Crack" o "John the Ripper" (ver la Sección crack ) a menudo pueden averiguar las contraseñas, a menos que tu contraseña sea lo suficientemente aleatoria. Los módulos PAM (ver abajo) te permiten usar una rutina de encriptación diferente con tus contraseñas (MD5 o parecidos). También puedes usar Crack en tu provecho. Considera el ejecutar periódicamente Crack contra tu base de datos de contraseñas, para encontrar contraseñas inseguras. Contacta entonces con el usuario afectado e instrúyelo para que cambie su contraseña.
Puedes ir a http://consult.cern.ch/writeup/security/security_3.html para más información sobre cómo elegir una buena contraseña.
Criptografía PGP y de Clave-Pública
La criptografía de clave pública, tal como la que usa PGP, usa una clave para encriptación y una clave para desencriptación. La criptografía tradicional, sin embargo, usa la misma clave para encriptación y desencriptación; esta clave debe ser conocida por las dos partes y ser transferida de alguna forma desde una a la otra con seguridad.
Para aliviar la necesidad de transmitir con seguridad la clave de encriptación, la encriptación de clave pública usa dos claves separadas: una clave pública y una clave privada. La clave pública de cada persona está disponible para que cualquiera haga la encriptación, mientras que, al mismo tiempo, cada persona mantiene su clave privada para descifrar los mensajes encriptados con la clave pública correcta.
Hay ventajas tanto en la criptografía de clave pública y de clave privada y se puede leer sobre sus diferencias en el RSA Cryptography FAQ, listado al final de esta sección.
PGP (Pretty Good Privacy) está bien soportado en Linux. Las versiones 2.6.2 y 5.0 se sabe que funcionan bien. Para una buena instrucción sobre PGP y cómo usarlo, echa un vistazo al FAQ de PGP: http://www.pgp.com/service/export/faq/55faq.cgi
Asegúrate de usar la versión que es aplicable en tu país. Debido a las restricciones a la exportación por parte del Gobierno de los USA, está prohibido que la encriptación fuerte sea transferida de forma electrónica fuera del país.
Los controles de USA sobre la exportación se rigen ahora por EAR (Export Administration Regulations). Ya no se gobiernan por ITAR.
Hay también una guía paso a paso para configurar PGP en Linux disponible en http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html. Fue escrita para la versión internacional de PGP, pero es adaptable fácilmente a la versión de los Estados Unidos. También puedes necesitar un patch para algunas de las últimas versiones de Linux; el patch está disponible en ftp://metalab.unc.edu/pub/Linux/apps/crypto.
Hay funcionando un proyecto sobre una re-implementación libre de pgp con fuente abierta. GnuPG es un sustituto completo y grátis de PGP. Porque no usa IDEA ni RSA puede usarse sin restricciones. GnuPG está casi de acuerdo con RFC2440 (OpenPGP). Ver la página web GNU Privacy Guard para más información: http://www.gpg.org/.
Más información sobre criptografía puede encontrarse en el FAQ de criptografía de RSA, disponible en http://www.rsa.com/rsalabs/newfaq/. Aquí encontrarás información sobre términos tales como "Diffie-Hellman", "criptografía de clave pública", "certificados digitales", etc.
SSL, S-HTTP, HTTPS y S/MIME
Con frecuencia los usuarios preguntan sobre las diferencias entre los diversos protocolos de seguridad y encriptación y sobre cómo usarlos. Aunque éste no es un documento sobre encriptación, es una buena idea explicar brevemente lo que es cada protocolo y dónde encontrar más información.
SSL: - SSL, o Secure Sockets Layer, es un método de encriptación desarrollado por Netscape para proveer de seguridad en Internet. Soporta diversos protocolos de encriptación diferentes y proporciona autentificación de cliente y servidor. SSL opera en el nivel de transporte, crea un canal seguro de datos encriptados, y así puede encriptar sin costuras datos de muchos tipos. Esto se ve más fácilmente cuando se va a un sitio seguro para ver un documento online seguro con Communicator, y sirve de base para comunicaciones seguras con Communicator, así como para muchas otras Comunicaciones de Netscape con encriptación de datos. Más información puede encontrarse en http://www.consensus.com/security/ssl-talk-faq.html. Hay información sobre otras implementaciones de seguridad de Netscape, y un buen punto de partida para estos protocolos, disponible en http://home.netscape.com/info/security-doc.html.
S-HTTP: - S-HTTP es otro protocolo que proporciona servicios de seguridad en Internet. Fue diseñado para proporcionar confidencialidad, autentificación, integridad y no repudiabilidad no puede confundirse con ningún otro], al tiempo que para soportar mecanismos de gestión de claves múltiples y algoritmos criptográficos mediante la negociación opcional entre las partes implicadas en cada transacción. S-HTTP está limitado al software específico que lo implementa, y encripta cada mensaje individualmente. [Del FAQ de Criptografía de RSA, página 138].
S/MIME: - S/MIME, o Secure Multipurpose Internet Mail Extension, es un estándar de encriptación usado para encriptar correo electrónico y otros tipos de mensajes en Internet. Es un estándar abierto desarrollado por RSA, así que es probable que lo veamos en Linux un día de estos. Más información sobre S/MIME puede encontrarse en http://home.netscape.com/assist/security/smime/overview.html.
Implementaciones IPSEC para Linux
Junto a CIPE y otras formas de encriptación de datos, hay también diversas otras implementaciones de IPSEC para Linux. IPSEC es un esfuerzo de la IETF para crear comunicaciones criptográficamente seguras a nivel de red IP y para proporcionar autentificación, integridad, control de acceso y confidencialidad. Información sobre IPSEC e Internet puede encontrarse en http://www.ietf.org/html.charters/ipsec-charter.html. También puedes encontrar enlaces a otros protocolos que implican gestión de claves, una lista de correo sobre IPSEC y ficheros.
La implementación del x-kernel de Linux, que se está desarrollando en la Universidad de Arizona, usa un entorno basado en el objeto para implementar protocolos de red llamados x-kernel y puede encontrarse en http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html. Dicho más sencillo, el x-kernel es un método de pasar mensajes a nivel de núcleo, lo que contribuye a una implementación más fácil.
Otra implementación IPSEC de libre disposición es el FreeS/WAN IPSEC de Linux. Su página web afirma,
"Estos servicios te permiten construir túneles seguros a través de redes inseguras. Todo lo que pasa a través de la red insegura es encriptado por la máquina pasarela IPSEC y desencriptado por la pasarela en el otro extremo. El resultado es la Red Privada Virtual (Virtual Private Network) o VPN. Esta es una red que es efectivamente privada, aún cuando incluye equipos en diversos sitios diferentes conectados mediante la insegura Internet."
Está disponible para descargar en http://www.xs4all.nl/~freeswan/ y ha alcanzado ya la 1.0 en el momento de escribir esto.
Al igual que otras formas de criptografía, no se distribuye por defecto con el núcleo debido a restrictiones a la exportación.
ssh (Shell Seguro) y stelnet
ssh y stelnet son programas que te permiten conectarte a sistemas remotos y tener una conexión encriptada.
ssh es un paquete de programas usados como un sustituto seguro para rlogin, rsh y rcp. Usa la criptografía de clave pública para encriptar comunicaciones entre dos hosts, asi como para autentificar usuarios. Puede usarse para conectar de forma segura a un host remoto o copiar datos entre hosts, al tiempo que se impiden los ataques hombre-en-medio (sesión hijacking) y el engaño de DNS. Realizará una compresión de datos en tus conexiones y comunicaciones X11 seguras entre hosts. La página principal de ssh puede encontrarse en http://www.cs.hut.fi/ssh/
También puedes usar ssh desde tu estación de trabajo Windows a tu servidor Linux ssh. Hay varias implementaciones de cliente de Windows libremente disponibles, incluyendo la que está en http://guardian.htu.tuwien.ac.at/therapy/ssh/ así como la implementación comercial de DataFellows, en http://www.datafellows.com/. Hay también un proyecto de fuente abierta para re-implementar ssh llamado "psst...". Para más información ver: http://www.net.lut.ac.uk/psst/
SSLeay es una implementación libre del protocolo Secure Sockets Layer de Netscape, desarrollado por Eric Young. Incluye diversas aplicaciones, tales como Secure para telnet, un módulo para Apache, diversas bases de datos y diversos algoritmos incluyendo DES, IDEA y Blowfish.
Usando esta librería se crea una sustitución segura de telnet que realiza la encriptación sobre una conexión telnet. A diferencia de SSH, stelnet usa SSL, el protocolo Secure Sockets Layer desarrollado por Netscape. Puedes encontrar Telnet Seguro y FTP Seguro, comenzando por el FAQ SSLeay, disponible en http://www.psy.uq.oz.au/~ftp/Crypto/.
SRP es otra implementación segura de telnet/ftp. De su página web:
"El proyecto SRP está desarrollando software de Internet seguro para uso libre en todo el mundo. Comenzando con una distribución de Telnet y FTP completamente segura, esperamos reemplazar los débiles sistemas de autentification en redes con sustitutos fuertes que no sacrifican la seguridad por la amigabilidad hacia el usuario. ¡La seguridad debe estar por defecto, no ser una opción!"
Para más información, ir a http://srp.stanford.edu/srp.
PAM - Módulos de Autentificación Enfuchables
Las versiones más recientes de la distribución Red Hat de Linux vienen con un esquema unificado de autentificación llamado "PAM". PAM te permite cambiar tus métodos y requisitos de autentificación al vuelo y encapsular todos los métodos de autentificación local sin recompilar ninguno de tus binarios. La configuración de PAM está más allá del alcance de este documento, pero no dejes de echar una ojeada al sitio web de PAM para más información. http://www.kernel.org/pub/linux/libs/pam/index.html.
Sólo unas pocas de las cosas que puedes hacer con PAM:
Usar otra encriptación distinta a DES para tus contraseñas. (Haciéndolas más difíciles a la decodificación por fuerza bruta)
Establecer límites de recursos sobre todos tus usuarios para que no puedan realizar ataques de negación-de-servicio (número de procesos, cantidad de memoria, etc)
Activar contraseñas sombra (ver debajo) al vuelo
Permitir a usuarios específicos conectar sólo en momentos específicos desde sitios específicos
Dedicar unas pocas horas a instalar y configurar tu sistema, puede impedir muchos ataques incluso antes de que ocurran. Por ejemplo, usa PAM para desactivar el uso por todo el sistema de ficheros .rhosts en los directorios home del usuario, añadiendo estas líneas a /etc/pam.d/rlogin: # # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts
Encapsulación IP Criptográfica (CIPE)
El objetivo primero de este software es proporcionar una facilidad para la interconexión segura de subredes (contra indiscreciones, incluyendo el análisis de tráfico y la inyección de mensaje falsificado) a lo largo de una red insegura de paquetes tal como es Internet.
CIPE encripta los datos a nivel de red. Los paquetes que viajan entre hosts por la red están encriptados. El motor de encriptación se sitúa cerca del controlador que envía y recibe los paquetes.
Esto es distinto a SSH, que encripta los datos mediante conexión, al nivel de socket. Se encripta una conexión lógica entre programas que se ejecutan en diferentes hosts.
CIPE puede usarse para hacer túneles, con el fin de crear una Red Privada Virtual (VPN). La encriptación de nivel bajo tiene la ventaja de que puede hacerse funcionar de forma transparente entre las dos redes conectadas en la VPN, sin ningún cambio en el software de aplicación.
Resumido de la documentación de CIPE:
Los estándares IPSEC definen un conjunto de protocolos que pueden ser usados (entre otras cosas) para construir VPNs encriptadas. Sin embargo, IPSEC es más bien un conjunto de protocolos de peso pesado y complicado con un montón de opciones, las implementaciones del conjunto completo de protocolos se usan aún raramente y algunos problemas (tales como gestión de claves) no están todavía completamente resueltos. CIPE usa un enfoque más simple, en el cual muchas cosas que pueden ser parametrizadas (tal como la elección del algoritmo de encriptación real usado) son una elección que se fija en el momento de la instalación. Esto limita la flexibilidad, pero permite una implementación simple (y por tanto eficiente, fácil de depurar...).
Más información puede encontrarse en http://www.inka.de/~bigred/devel/cipe.html
Al igual que otras formas de criptografía, no es distribuída con el núcleo por defecto debido a restricciones a la exportación.
Kerberos
Kerberos es un sistema de autentificación desarrollado por el Proyecto Athena en el MIT. Cuando un usuario se conecta, Kerberos autentifica a este usuario (usando una contraseña) y proporciona al usuario una forma de probar su identidad a otros servidores y hosts esparcidos por toda de la red.
Después, esta autentificación se usa por programas como rlogin para permitir al usuario conectar con otros hosts sin una contraseña (en lugar del fichero .rhosts). Este método de autentificación también puede usarse por el sistema de correo para garantizar que el correo se entrega a la persona correcta, así como para garantizar que el remitente es quien dice ser.
Kerberos y los otros programas que vienen con él, impide a los usuarios "engañar" al sistema haciéndole creer que son otros distintos. Desafortunadamente, instalar Kerberos es muy intrusivo, al requerir la modificación o sustitución de numerosos programas estándar.
Puedes encontrar más información sobre kerberos mirando en el kerberos FAQ y el código puede encontrarse en http://nii.isi.edu/info/kerberos/.
[De: Stein, Jennifer G., Clifford Neuman, y Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]
Kerberos no debería ser tu primer paso para mejorar la seguridad de tu host. Es bastante embrollado y no se usa tan ampliamente como, digamos, SSH.
Contraseñas Sombra.
Las contraseñas sombra son un medio de mantener secreta, para los usuarios normales, la información de tu contraseña cifrada. Normalmente, estas contraseñas encriptadas se almacenan en el fichero /etc/passwd de lectura para todos. Cualquiera puede ejecutar sobre ellas programas que averiguan contraseñas e intentar determinar lo que son. Las contraseñas sombra, por el contrario, se archivan en /etc/shadow, que sólo pueden leer los usuarios privilegiados. Para usar contraseñas sombra, necesitas asegurarte de que todas tus utilidades que necesiten acceso a la información de la contraseña sean recompiladas para soportarlas. PAM (ver más arriba) también te permite sólo enchufar un módulo de sombra; no requiere la re-compilación de los ejecutables. Puedes acudir al Contraseña-Sombra COMO para información adicional si es necesario. Está disponible en http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html Su fecha es más bien reciente y no se necesita en las distribuciones que soporten PAM.
"Crack" y "John the Ripper"
Si por alguna razón tu programa passwd no impone contraseñas difíciles de averiguar, podrías querer ejecutar un programa rompedor de contraseñas y asegurarte de que las contraseñas de tus usuarios son seguras.
Los programas rompedores de contraseñas operan sobre una idea simple: prueban cada palabra del diccionario, y después las variaciones de estas palabras, encriptando cada una y comprobándola frente a tu contraseña encriptada. Si obtienen una que case, saben cuál es tu contraseña.
Hay muchos programas por ahí... los dos más notables son "Crack" y "John the Ripper" ( http://www.false.com/security/john/index.html). Te llevarán un montón de tiempo de cpu, pero solo sabrás si un atacante podría lograr usarlas si las ejecutas tú mismo primero y notificas a los usuarios con contraseñas débiles. Ten en cuenta que un atacante tendría que usar primero algún otro agujero para leer tu fichero /etc/passwd, pero tales agujeros son más comúnes de lo que podrías pensar.
Dado que la seguridad es sólo tan fuerte como el host más inseguro, vale la pena mencionar que si tienes algunos equipos Windows en tu red, deberías probar L0phtCrack, un programa de Crack para Windows. Está disponible en http://www.l0pht.com/
CFS - Sistema de Fichero Criptográfico y TCFS - Sistema de Fichero Criptográfico Transparente
CFS es una forma de encriptar árboles de directorios completos y permitir a los usuarios almacenar en ellos ficheros encriptados. Usa un servidor NFS que se ejecuta sobre una máquina local. Los RPMS están disponibles en http://www.replay.com/redhat/ y más información sobre cómo funcionan está en ftp://ftp.research.att.com/dist/mab/.
TCFS mejora a CFS añadiendo más integración con el sistema de ficheros, de modo que el sistema de ficheros que está encriptado es transparente para los usuarios. Más información en: http://edu-gw.dia.unisa.it/tcfs/.
Tampoco necesita usarse con sistemas de achivos completos. Funciona en árboles de directorios también.
X11, SVGA y seguridad de pantalla
X11
Es importante que asegures tu pantalla gráfica para impedir que los atacantes se apropien de tus contraseñas cuando las escribas, puedan leer los documentos o la información que estás leyendo en pantalla o, incluso, usar un agujero para lograr acceso de root. Ejecutar las aplicaciones X remotas sobre una red también puede ser peligroso, permitiendo a los reastreadores ver toda tu interacción con el sistema remoto.
X tiene varios mecanismos de control de acceso. El más simple de ellos está basado en el host: usas xhost para especificar a qué hosts se les permite acceder a tu pantalla. Esto no es seguro en absoluto, porque si alguien tiene acceso a tu máquina, puede hacer xhost + su máquina y obtenerlo fácilmente. Igualmente, si tienes que conceder acceso desde una máquina que no es de confianza, desde ahí cualquiera puede comprometer tu pantalla.
Cuando se usa xdm (Gestor X de Pantalla) para conectar, se obtiene un método de acceso mucho mejor: MIT-MAGIC-COOKIE-1. Se genera una "cookie" de 128-bit y se almacena en tu fichero .Xauthority. Si necesitas conceder acceso a tu pantalla a una máquina remota, puedes usar el comando xauth y la información en tu fichero .Xauthority para proporcionar acceso sólo a esa conexión. Ver el mini-cómo de Remote-X-Apps, disponible en http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.
Puedes usar también ssh (ver ssh , arriba) para permitir conexiones X seguras. Esto tiene la ventaja de que también es transparente para el usuario final y significa que ningún dato no encriptado fluye a lo largo de la red.
Echa un vistazo a la página Xsecurity del manual para más información sobre seguridad X. La apuesta más segura es usar xdm para conectar tu consola y luego usar ssh para ir a sitios remotos sobre los que puedes ejecutar programas X.
SVGA
Los programas SVGAlib normalmente son SUID-root para acceder a todo el hardware de vídeo de tu Linux. Esto los hace muy peligrosos. Si fallan, lo normal es que necesites reiniciar tu equipo para tener de nuevo una consola usable. Asegúrate de que cualesquiera programas SVGA que ejecutes sean auténticos y pueda al menos haber algo de confianza. Aún mejor, no ejecutes ninguno para nada.
GGI (Proyecto de Interface Gráfico Genérico)
El proyecto GGI de Linux está intentando solucionar diversos problemas con los interfaces de vídeo en Linux. GGI cambiará una pequeña parte del código de vídeo en el núcleo de Linux y así controlará el acceso al sistema de vídeo. Esto significa que GGI será capaz en cualquier momento de restaurar en tu consola un estado deseable conocido. También permitirá una clave de atención segura, para que puedas estar seguro de que no hay ningún programa troyano de login ejecutándose en tu consola. http://synergy.caltech.edu/~ggi/
Seguridad del Núcleo
Se hace una descripción de las opciones de configuración del núcleo que se relacionan con la seguridad y una explicación de lo que hacen y de cómo usarlas.
Dado que el núcleo controla el funcionamiento en red de tu computadora, es importante que sea muy seguro y no se vea comprometido. Para impedir alguno de los más recientes ataques de redes, debes procurar mantener actualizada la versión de tu núcleo. Puedes encontrar nuevos núcleos en ftp://ftp.kernel.org/ o a través de tu vendedor de distribuciones.
Hay también un grupo internacional que proporciona un único crypto parche unificado para el núcleo de linux más extendido. Este parche da soporte para una gran cantidad de subsistemas criptográficos y otras cosas que no pueden incluirse en el núcleo principal debido a las restricciones de exportación. Para más información, visita su página web en: http://www.kerneli.org/
Opciones para Compilar el Núcleo 2.0
Para los núcleos 2.0.x, se aplican las opciones que siguen. Debes ver estas opciones durante el proceso de configuración del núcleo. Muchos de los comentarios que se hacen están tomados de ./linux/Documentation/Configure.help, que es el mismo documento al que se hace referencia cuando se usa la facilidad de Ayuda durante la etapa de make config de compilación del núcleo.
Cortafuegos de Red (CONFIG_FIREWALL)
Esta opción debe estar encendida (on) si quieres ejecutar cualquier cortafuegos o enmascaramiento en tu equipo linux. Si sólo vas a ser una máquina cliente regular, es más seguro decir no.
IP: reenviar/pasarelas (CONFIG_IP_FORWARD)
Si activas el reenvío de IP, tu equipo Linux esencialmente se convierte en un enrutador. Si tu máquina está en una red, podrías estar reenviando datos desde una red a otra, y quizás subvirtiendo un cortafuegos que se puso ahí para impedir que esto sucediera. Los usuarios telefónicos normales deberán desactivar esto y los otros usuarios deberían meditar sobre las implicaciones de seguridad que tiene hacer esto. Los equipos cortafuegos deberán tenerlo activado y usarlo en conjunción con software de cortafuegos.
Puedes activar el reenvio de IP de una forma dinámica usando el siguiente comando: root# echo 1 > /proc/sys/net/ipv4/ip_forward
y desactivarlo con el comando: root# echo 0 > /proc/sys/net/ipv4/ip_forward
Recuerda que los ficheros, y sus tamaños, no reflejan sus tamaños reales y que a pesar de ser de longitud cero, pueden serlo o no.
IP: syn cookies (CONFIG_SYN_COOKIES)
Un "Ataque SYN" es un ataque de negación de servicio (DoS) que consume todos los recursos de tu equipo, obligándote a reiniciarlo. No se nos ocurre ni una sola razón por la que, normalmente, no querrías activar esto. En la serie de núcleo 2.1 esta opción config solamente permite las syn cookies, pero no las activa. Para activarlas, tienes que hacer: root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
IP: Cortafuegos (CONFIG_IP_FIREWALL)
Esta opción es necesaria si vas a configurar tu equipo como cortafuegos, vas a hacer enmascaramiento o si deseas proteger a tu equipo de conexión telefónica de que alguien entre por la vía de tu interfaz de marcado PPP.
IP: registro de paquetes del cortafuegos (CONFIG_IP_FIREWALL_VERBOSE)
Esta opción te da información sobre los paquetes que ha recibido tu cortafuegos, como remitente, receptor, puerto, etc.
IP: Suprimir sistema de enrutado de origen (CONFIG_IP_NOSR)
Esta opción debe estar activada. Los sistemas de enrutado de origen contienen dentro del paquete el camino completo hasta su destino. Esto quiere decir que los enrutadores a través de los cuales va el paquete no necesitan inspeccionarlo, sino sólo reenviarlo. Esto podría conducir a que entren datos en tu sistema que pueden ser un exploit potencial.
IP: Enmascaramiento (CONFIG_IP_MASQUERADE) Si uno de los computadores de tu red local, para el cual tu equipo Linux actúa como cortafuegos, quiere enviar algo al exterior, tu equipo puede "enmascararse" como este host, esto es, reenvía el tráfico al destino solicitado, pero hace que parezca como si viniera del equipo cortafuegos mismo. Ver http://www.indyramp.com/masq para más información.
IP: enmascaramiento ICMP (CONFIG_IP_MASQUERADE_ICMP) Esta opción añade enmascaramiento ICMP a la opción previa de sólo enmascaramiento de tráfico TCP o UDP.
IP: soporte proxy transparente (CONFIG_IP_TRANSPARENT_PROXY) Esto capacita a tu cortafuegos Linux para redirigir de forma transparente cualquier tráfico de red, con origen en la red local y destinado a un host remoto, a un servidor local, llamado "servidor proxy transparente". Esto hace que los computadores locales piensen que están hablando con el extremo remoto, cuando de hecho están conectados a un proxy local. Ver el COMO IP-Masquerading y http://www.indyramp.com/masq para más información.
IP: desfragmentar siempre (CONFIG_IP_ALWAYS_DEFRAG)
Generalmente esta opción está desactivada, pero si estás construyendo un cortafuegos, o un host de enmascaramiento, querrás activarla. Cuando se envían datos de un host a otro, no siempre se logra enviarlos como un único paquete de datos, sino más bien se fragmentan en diversas piezas. El problema con esto es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que cualquiera puede insertar en los restantes paquetes información que no se sabe que está ahí. Podría también impedir un ataque lágrima (teardrop) contra un host interno que todavía no esté parcheado contra él.
Firmas de Paquetes (CONFIG_NCPFS_PACKET_SIGNING)
Esta es una opción disponible en la serie 2.1 del núcleo que firmará los paquetes NCP para mayor seguridad. Normalmente puedes dejarlo desactivado, pero está ahí por si lo necesitas.
IP: Dispositivo de enlace en red de paquetes de cortafuegos (CONFIG_IP_FIREWALL_NETLINK)
Esta es una opción realmente esmerada que te permite analizar los primeros 128 bytes de los paquetes de un programa de espacio de usuario, para determinar si te gustaría aceptar o rechazar el paquete, basándote en su validez.
Opciones para Compilar el Núcleo 2.2
Para los núcleos 2.2.x, muchas de las opciones son las mismas, pero se han desarrollado unas pocas nuevas. Muchos de los comentarios que se hacen aquí se han tomado de ./linux/Documentation/Configure.help, que es el mismo documento al que se hace referencia cuando se usa la facilidad Ayuda durante la etapa make config de compilación del núcleo. Sólo se listan debajo las opciones añadidas recientemente. Consulta la descripción del 2.0 para ver una lista de otras opciones necesarias. El cambio más importante en la serie 2.2 del núcleo es el código IP de cortafuegos. Para instalar el IP del cortafuegos ahora se usa el programa ipchains, en vez del ipfwadm que se usa en el núcleo 2.0.
Filtrado de Socket (CONFIG_FILTER)
Para la mayoría de la gente, lo seguro es decir no a esta opción. Esta opción te permite conectar en espacio de usuario un filtro a cualquier socket y determinar si los paquetes deben aceptarse o rechazarse. A menos que tengas una necesidad muy específica y seas capaz de programar tal filtro, debes decir no. También ten en cuenta que según este escrito, todos los protocolos fueron admitidos excepto TCP.
Reenvío de Puerto
El reenvío de puerto es un añadido al Enmascaramiento de IP que permite algún reenvío de paquetes desde el exterior al interior de un cortafuegos por unos puertos dados. Esto podría ser útil si, por ejemplo, quieres ejecutar un servidor de web detrás del cortafuegos o enmascarar el host y que el servidor de web fuese accesible desde el mundo exterior. Un cliente externo envía una petición al puerto 80 del cortafuegos, el cortafuegos reenvía esta petición al servidor de web, el servidor de web tramita la petición y los resultados se envían a través del cortafuegos al cliente original. El cliente piensa que la misma máquina cortafuegos está ejecutando el servidor web. Esto también puede usarse para equilibrar cargas si tienes un grupo de servidores web idénticos detrás del cortafuegos. Información sobre esta característica está disponible en http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (para leer el WWW, necesitas tener acceso a un equipo en Internet que tenga un programa como lynx o netscape). Para información general, ver por favor ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/
Filtrado de Socket (CONFIG_FILTER)
Usando esta opción, los programas de espacio de usuario pueden adjuntar un filtro para cualquier socket y por ello decirle al núcleo que debe permitir o no permitir a ciertos tipos de datos pasar a través del socket. El filtro de socket de Linux funciona con todos los tipos de socket, excepto el TCP por ahora. Ver el fichero de texto ./linux/Documentation/networking/filter.txt para más información.
IP: Enmascaramiento
El enmascaramiento del núcleo 2.2 ha sido mejorado. Proporciona soporte adicional para protocolos especiales para enmascaramiento, etc. No dejes de leer el Cadenas IP COMO para más información.
Dispositivos de Núcleo
Hay unos pocos dispositivos de bloque y de carácter disponibles en Linux que te ayudarán también con la seguridad.
Los dos dispositivos /dev/random y /dev/urandom se proveen por el núcleo para proporcionar datos aleatorios en todo momento.
Ambos, /dev/random y /dev/urandom, deberían ser bastante seguros de usar al generar claves PGP, desafíos ssh y otras aplicaciones para las que los números aleatorios sean un requisito. Dada cualquier secuencia inicial de números, los atacantes serán incapaces de predecir el número siguiente a partir de esas fuentes. Hay gran cantidad de esfuerzo puesto en asegurar que los números que se obtienen de esas fuentes son aleatorios en cualquier sentido de la palabra.
La única diferencia es que a /dev/random se le agotan los bytes aleatorios y te hace esperar hasta que sean acumulados más. Ten en cuenta que algunos sistemas pueden bloquearse durante mucho tiempo de espera hasta que una entrada generada por un nuevo usuario sea introducida en el sistema. Tienes que tener cuidado antes de usar /dev/random. (Quizás lo mejor que puede hacerse es usarlo cuando estés generando información en clave sensible y decirle al usuario que aporree el teclado repetidamente hasta que tú imprimas "OK, suficiente".)
/dev/random es entropía de alta calidad, generada al medir los tiempos entre interrupciones, etc. Se bloquea hasta que estén disponibles suficientes bits de datos aleatorios.
/dev/urandom es similar, pero cuando el almacén de entropía se ejecuta bajo, devolverá un embrollo criptográficamente potente de lo que hay. Esto no es seguro, pero es suficiente para la mayoría de las aplicaciones.
Puedes leer desde los dispositivos usando algo como: root# head -c 6 /dev/urandom mmencode
Esto imprimirá seis caracteres aleatoriamente en la consola, adecuados para la generación de contraseñas. Puedes encontrar mmencode en el paquete metamail.
Ver /usr/src/linux/drivers/char/random.c para una descripción del algoritmo.
Gracias a Theodore Y. Ts'o, Jon Lewis y otros de Linux-kernel por ayudarme (a Dave) con esto.
Dado que el núcleo controla el funcionamiento en red de tu computadora, es importante que sea muy seguro y no se vea comprometido. Para impedir alguno de los más recientes ataques de redes, debes procurar mantener actualizada la versión de tu núcleo. Puedes encontrar nuevos núcleos en ftp://ftp.kernel.org/ o a través de tu vendedor de distribuciones.
Hay también un grupo internacional que proporciona un único crypto parche unificado para el núcleo de linux más extendido. Este parche da soporte para una gran cantidad de subsistemas criptográficos y otras cosas que no pueden incluirse en el núcleo principal debido a las restricciones de exportación. Para más información, visita su página web en: http://www.kerneli.org/
Opciones para Compilar el Núcleo 2.0
Para los núcleos 2.0.x, se aplican las opciones que siguen. Debes ver estas opciones durante el proceso de configuración del núcleo. Muchos de los comentarios que se hacen están tomados de ./linux/Documentation/Configure.help, que es el mismo documento al que se hace referencia cuando se usa la facilidad de Ayuda durante la etapa de make config de compilación del núcleo.
Cortafuegos de Red (CONFIG_FIREWALL)
Esta opción debe estar encendida (on) si quieres ejecutar cualquier cortafuegos o enmascaramiento en tu equipo linux. Si sólo vas a ser una máquina cliente regular, es más seguro decir no.
IP: reenviar/pasarelas (CONFIG_IP_FORWARD)
Si activas el reenvío de IP, tu equipo Linux esencialmente se convierte en un enrutador. Si tu máquina está en una red, podrías estar reenviando datos desde una red a otra, y quizás subvirtiendo un cortafuegos que se puso ahí para impedir que esto sucediera. Los usuarios telefónicos normales deberán desactivar esto y los otros usuarios deberían meditar sobre las implicaciones de seguridad que tiene hacer esto. Los equipos cortafuegos deberán tenerlo activado y usarlo en conjunción con software de cortafuegos.
Puedes activar el reenvio de IP de una forma dinámica usando el siguiente comando: root# echo 1 > /proc/sys/net/ipv4/ip_forward
y desactivarlo con el comando: root# echo 0 > /proc/sys/net/ipv4/ip_forward
Recuerda que los ficheros, y sus tamaños, no reflejan sus tamaños reales y que a pesar de ser de longitud cero, pueden serlo o no.
IP: syn cookies (CONFIG_SYN_COOKIES)
Un "Ataque SYN" es un ataque de negación de servicio (DoS) que consume todos los recursos de tu equipo, obligándote a reiniciarlo. No se nos ocurre ni una sola razón por la que, normalmente, no querrías activar esto. En la serie de núcleo 2.1 esta opción config solamente permite las syn cookies, pero no las activa. Para activarlas, tienes que hacer: root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
IP: Cortafuegos (CONFIG_IP_FIREWALL)
Esta opción es necesaria si vas a configurar tu equipo como cortafuegos, vas a hacer enmascaramiento o si deseas proteger a tu equipo de conexión telefónica de que alguien entre por la vía de tu interfaz de marcado PPP.
IP: registro de paquetes del cortafuegos (CONFIG_IP_FIREWALL_VERBOSE)
Esta opción te da información sobre los paquetes que ha recibido tu cortafuegos, como remitente, receptor, puerto, etc.
IP: Suprimir sistema de enrutado de origen (CONFIG_IP_NOSR)
Esta opción debe estar activada. Los sistemas de enrutado de origen contienen dentro del paquete el camino completo hasta su destino. Esto quiere decir que los enrutadores a través de los cuales va el paquete no necesitan inspeccionarlo, sino sólo reenviarlo. Esto podría conducir a que entren datos en tu sistema que pueden ser un exploit potencial.
IP: Enmascaramiento (CONFIG_IP_MASQUERADE) Si uno de los computadores de tu red local, para el cual tu equipo Linux actúa como cortafuegos, quiere enviar algo al exterior, tu equipo puede "enmascararse" como este host, esto es, reenvía el tráfico al destino solicitado, pero hace que parezca como si viniera del equipo cortafuegos mismo. Ver http://www.indyramp.com/masq para más información.
IP: enmascaramiento ICMP (CONFIG_IP_MASQUERADE_ICMP) Esta opción añade enmascaramiento ICMP a la opción previa de sólo enmascaramiento de tráfico TCP o UDP.
IP: soporte proxy transparente (CONFIG_IP_TRANSPARENT_PROXY) Esto capacita a tu cortafuegos Linux para redirigir de forma transparente cualquier tráfico de red, con origen en la red local y destinado a un host remoto, a un servidor local, llamado "servidor proxy transparente". Esto hace que los computadores locales piensen que están hablando con el extremo remoto, cuando de hecho están conectados a un proxy local. Ver el COMO IP-Masquerading y http://www.indyramp.com/masq para más información.
IP: desfragmentar siempre (CONFIG_IP_ALWAYS_DEFRAG)
Generalmente esta opción está desactivada, pero si estás construyendo un cortafuegos, o un host de enmascaramiento, querrás activarla. Cuando se envían datos de un host a otro, no siempre se logra enviarlos como un único paquete de datos, sino más bien se fragmentan en diversas piezas. El problema con esto es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que cualquiera puede insertar en los restantes paquetes información que no se sabe que está ahí. Podría también impedir un ataque lágrima (teardrop) contra un host interno que todavía no esté parcheado contra él.
Firmas de Paquetes (CONFIG_NCPFS_PACKET_SIGNING)
Esta es una opción disponible en la serie 2.1 del núcleo que firmará los paquetes NCP para mayor seguridad. Normalmente puedes dejarlo desactivado, pero está ahí por si lo necesitas.
IP: Dispositivo de enlace en red de paquetes de cortafuegos (CONFIG_IP_FIREWALL_NETLINK)
Esta es una opción realmente esmerada que te permite analizar los primeros 128 bytes de los paquetes de un programa de espacio de usuario, para determinar si te gustaría aceptar o rechazar el paquete, basándote en su validez.
Opciones para Compilar el Núcleo 2.2
Para los núcleos 2.2.x, muchas de las opciones son las mismas, pero se han desarrollado unas pocas nuevas. Muchos de los comentarios que se hacen aquí se han tomado de ./linux/Documentation/Configure.help, que es el mismo documento al que se hace referencia cuando se usa la facilidad Ayuda durante la etapa make config de compilación del núcleo. Sólo se listan debajo las opciones añadidas recientemente. Consulta la descripción del 2.0 para ver una lista de otras opciones necesarias. El cambio más importante en la serie 2.2 del núcleo es el código IP de cortafuegos. Para instalar el IP del cortafuegos ahora se usa el programa ipchains, en vez del ipfwadm que se usa en el núcleo 2.0.
Filtrado de Socket (CONFIG_FILTER)
Para la mayoría de la gente, lo seguro es decir no a esta opción. Esta opción te permite conectar en espacio de usuario un filtro a cualquier socket y determinar si los paquetes deben aceptarse o rechazarse. A menos que tengas una necesidad muy específica y seas capaz de programar tal filtro, debes decir no. También ten en cuenta que según este escrito, todos los protocolos fueron admitidos excepto TCP.
Reenvío de Puerto
El reenvío de puerto es un añadido al Enmascaramiento de IP que permite algún reenvío de paquetes desde el exterior al interior de un cortafuegos por unos puertos dados. Esto podría ser útil si, por ejemplo, quieres ejecutar un servidor de web detrás del cortafuegos o enmascarar el host y que el servidor de web fuese accesible desde el mundo exterior. Un cliente externo envía una petición al puerto 80 del cortafuegos, el cortafuegos reenvía esta petición al servidor de web, el servidor de web tramita la petición y los resultados se envían a través del cortafuegos al cliente original. El cliente piensa que la misma máquina cortafuegos está ejecutando el servidor web. Esto también puede usarse para equilibrar cargas si tienes un grupo de servidores web idénticos detrás del cortafuegos. Información sobre esta característica está disponible en http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (para leer el WWW, necesitas tener acceso a un equipo en Internet que tenga un programa como lynx o netscape). Para información general, ver por favor ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/
Filtrado de Socket (CONFIG_FILTER)
Usando esta opción, los programas de espacio de usuario pueden adjuntar un filtro para cualquier socket y por ello decirle al núcleo que debe permitir o no permitir a ciertos tipos de datos pasar a través del socket. El filtro de socket de Linux funciona con todos los tipos de socket, excepto el TCP por ahora. Ver el fichero de texto ./linux/Documentation/networking/filter.txt para más información.
IP: Enmascaramiento
El enmascaramiento del núcleo 2.2 ha sido mejorado. Proporciona soporte adicional para protocolos especiales para enmascaramiento, etc. No dejes de leer el Cadenas IP COMO para más información.
Dispositivos de Núcleo
Hay unos pocos dispositivos de bloque y de carácter disponibles en Linux que te ayudarán también con la seguridad.
Los dos dispositivos /dev/random y /dev/urandom se proveen por el núcleo para proporcionar datos aleatorios en todo momento.
Ambos, /dev/random y /dev/urandom, deberían ser bastante seguros de usar al generar claves PGP, desafíos ssh y otras aplicaciones para las que los números aleatorios sean un requisito. Dada cualquier secuencia inicial de números, los atacantes serán incapaces de predecir el número siguiente a partir de esas fuentes. Hay gran cantidad de esfuerzo puesto en asegurar que los números que se obtienen de esas fuentes son aleatorios en cualquier sentido de la palabra.
La única diferencia es que a /dev/random se le agotan los bytes aleatorios y te hace esperar hasta que sean acumulados más. Ten en cuenta que algunos sistemas pueden bloquearse durante mucho tiempo de espera hasta que una entrada generada por un nuevo usuario sea introducida en el sistema. Tienes que tener cuidado antes de usar /dev/random. (Quizás lo mejor que puede hacerse es usarlo cuando estés generando información en clave sensible y decirle al usuario que aporree el teclado repetidamente hasta que tú imprimas "OK, suficiente".)
/dev/random es entropía de alta calidad, generada al medir los tiempos entre interrupciones, etc. Se bloquea hasta que estén disponibles suficientes bits de datos aleatorios.
/dev/urandom es similar, pero cuando el almacén de entropía se ejecuta bajo, devolverá un embrollo criptográficamente potente de lo que hay. Esto no es seguro, pero es suficiente para la mayoría de las aplicaciones.
Puedes leer desde los dispositivos usando algo como: root# head -c 6 /dev/urandom mmencode
Esto imprimirá seis caracteres aleatoriamente en la consola, adecuados para la generación de contraseñas. Puedes encontrar mmencode en el paquete metamail.
Ver /usr/src/linux/drivers/char/random.c para una descripción del algoritmo.
Gracias a Theodore Y. Ts'o, Jon Lewis y otros de Linux-kernel por ayudarme (a Dave) con esto.
Seguridad de Red
La seguridad de la red está llegando a ser cada vez más importante en la medida en que la gente pasa cada vez más tiempo conectada. Comprometer la seguridad de la red es, con frecuencia, mucho más fácil que comprometer la seguridad física o la local y es mucho más común.
Hay un conjunto de buenas herramientas para ayudar con la seguridad de la red y muchísimas de ellas vienen en las distribuciones de Linux.
Husmeadores de Paquetes
Una de las maneras más comunes por la que los intrusos logran acceder a más sistemas en tu red es empleando un husmeador de paquetes sobre un host ya comprometido. Este "husmeador" sólo escucha sobre el puerto Ethernet cosas como passwd y login y su que van en la corriente de paquetes y entonces registra el tráfico después de esto. De esta forma, los atacantes logran contraseñas para sistemas que aún no han intentado abordar. Las contraseñas de texto-claro son muy vulnerables a este ataque.
Ejemplo: El host A ha sido comprometido. El atacante instala un husmeador. El husmeador recoge las conexiones de administrador en el Host B desde el Host C. Logra la contraseña personal del administrador cuando conecta a B. Entonces, el administrador hace un su para arreglar el problema. Ahora ellos tienen la contraseña de root para el Host B. Más tarde el administrador deja a alguien hacer telnet desde su cuenta al Host Z en otro sitio. Ahora el atacante tiene una contraseña/conexión en el Host Z.
En este momento el atacante siquiera necesita comprometer un sistema para hacer esto: podría también meter un portátil o un pc en un edificio y pinchar en tu red.
Usar ssh u otros métodos de contraseña encriptada frustra este ataque. Cosas como APOP para cuentas POP también previenen este ataque. (Los logins POP normales son muy vulnerables a esto, como todo lo que envíe contraseñas en texto-claro por la red.)
Servicios de Sistema y Grapadores de tcp
Antes de poner tu sistema Linux en CUALQUIER red lo primero que tienes que mirar es qué servicios necesitas ofrecer. Los servicios que no necesites ofrecer deben ser desactivados para que tengas una cosa menos de la que preocuparte y los atacantes tengan un lugar menos en el que buscar un agujero.
Hay un montón de formas de desactivar servicios bajo Linux. Puedes mirar en tu fichero /etc/inetd.conf y ver qué servicios se están ofreciendo en tu inetd. Desactiva cualquiera que no necesites descomentándolos (# al principio de la línea), y luego envia tu proceso inetd a SIGHUP.
También puedes quitar (o descomentar) servicios en tu fichero /etc/services. Esto implicará que los clientes locales también serán incapaces de encontrar el servicio (p.e., si quitas ftp y tratas de hacer ftp a un sitio remoto desde esa máquina, fallará y te dará un mensaje de "servicio desconocido"). Normalmente no merece la pena quitar servicios, dado que no proporciona seguridad adicional. Si una persona local quiere usar ftp, incluso aunque tú lo hayas descomentado, haría que su propio cliente use el puerto común FTP y aún funcionaría mejor.
Algunos de los servicios que querrías dejar habilitados son:
ftp
telnet (o ssh)
mail, tal como pop-3 o imap
identd
Si sabes que no vas a usar algún paquete en particular, puedes borrarlo por completo. En la distribución Red Hat, rpm -e nombrepaquete borra el paquete entero. En la Debian dpkg --remove hace lo mismo.
Además, realmente deberías desactivar las utilidades rsh/rlogin/rcp, incluyendo login (usado por rlogin), shell (usado por rcp) y exec (usado por rsh) para que no se inicien en /etc/inetd.conf. Estos protocolos son extremadamente inseguros y han sido la causa de exploits en el pasado.
Debes comprobar tu /etc/rc.d/rcN.d, (donde N es el nivel de ejecución de tus sistemas) y ver si alguno de los servidores arrancados en ese directorio no se necesita. Los ficheros en /etc/rc.d/rcN.d son realmente enlaces simbólicos al directorio /etc/rc.d/init.d. Renombrar los ficheros en el directorio init.d tiene el efecto de inhabilitar todos los enlaces simbólicos en /etc/rc.d/rcN.d. Si sólo quieres deshabilitar un servicio para un nivel de ejecución particular, renombra el fichero apropiado sustituyendo la S mayúscula por una s minúscula, como esto: root# cd /etc/rc6.d root# mv S45dhcpd s45dhcpd
Si tienes ficheros estilo BSD rc, tienes que probar /etc/rc* para los programas que no necesites.
La mayoría de las distribuciones de Linux vienen con grapadores de tcp "grapando" todos tus servicios TCP. Un grapador de tcp (tcpd) se pide desde inetd en lugar del servidor real. Entonces tcpd chequea el host que está requiriendo el servicio y, o bien ejecuta el servidor real, o niega el acceso desde este host. tcpd te permite restringir el acceso a tus servicios TCP. Debes hacer un /etc/hosts.allow y añadir sólo aquellos hosts que necesiten tener acceso a los servicios de tu equipo.
Si eres un usuario telefónico doméstico, te sugerimos que niegues TODOS. tcpd también registra los intentos fallidos de acceder a servicios, así que esto te puede dar la alerta si te están atacando. Si añades nuevos servicios, debes asegurarte de configurarlos para usar grapadores de tcp si están basados en TCP. Por ejemplo, un usuario telefónico normal puede impedir a los extraños la conexión a su máquina, sin perder la capacidad de recuperar correo y hacer conexiones de red a Internet. Para hacer esto, debes añadir lo siguiente a tu /etc/hosts.allow:
ALL: 127.
Y por supuesto /etc/hosts.deny contendría:
ALL: ALL
que impedirá conexiones externas a tu máquina, pero permitiéndote desde el interior conectar a los servidores en Internet.
Ten en cuenta que los grapadores de tcp sólo protegen servicios ejecutados desde inetd y unos pocos otros selectos. Muy bien podría haber otros servicios ejecutándose en tu máquina. Puedes usar netstat -ta para encontrar una lista de todos los servicios que está ofreciendo tu máquina.
Verifica tu Información DNS
Mantener al día la información DNS sobre todos los hosts en tu red puede ayudar a incrementar la seguridad. Si un host no autorizado llega a conectarse a tu red, puedes reconocerlo por su carencia de una entrada DNS. Muchos servicios pueden estar configurados para no aceptar conexiones de hosts que no tienen entradas DNS válidas.
identd
identd es un pequeño programa que normalmente se ejecuta fuera de tu servidor inetd. Mantiene un registro de qué usuario está ejecutando qué servicio TCP, y luego informa de esto a quien se lo pregunta.
Mucha gente no entiende la utilidad de identd y por eso lo desactiva o bloquea todas las peticiones de sitios. identd no está para ayudar a sitios remotos. No hay modo de saber si el dato que obtienes del identd remoto es correcto o no. No hay autentificación en las peticiones de identd.
¿Por qué habrías de ejecutarlo entonces? Porque te ayuda, y es otro punto de datos para el seguimiento. Si tu identd no está comprometido, entonces sabes que está diciendo el nombre de usuario o uid de sitios remotos que usan los servicios TCP. Si el administrador de un sitio remoto te responde y te dice que el usuario tal-y-tal estaba tratando de hacer hack en su sitio, puedes fácilmente emprender una acción en contra de este usuario. Si no estás ejecutando identd, tendrás que mirar en montones y montones de registros de log, calcular quién estaba conectado en ese momento y, en general, gastar mucho más tiempo en rastrear al usuario.
El identd que viene con la mayoría de las distribuciones es más configurable de lo que mucha gente piensa. Puedes deshabilitarlo para usuarios específicos (ellos pueden hacer un fichero .noident), puedes registrar todas las solicitudes de identd (lo recomendamos), además puedes poner identd para que devuelva un uid en vez de un nombre de usuario o incluso NO-USER.
SATAN, ISS y Otros Exploradores de Red
Hay un conjunto de paquetes de software diferentes que hacen de puerto y dan servicio basados en la exploración de equipos o redes. SATAN, ISS, SAINT y Nessus son algunos de los más conocidos. Este software se conecta al equipo destino (o a todos los equipos destino en una red) en todos los puertos que puede, e intenta determinar qué servicio está ejecutándose ahí. Basado en esta información, puede decir si el equipo es vulnerable a un exploit específico en este servidor.
SATAN (Security Administrator's Tool for Analyzing Networks) (Herramienta de Administrador de Seguridad para Analizar Redes) es un explorador de puerto con una interfaz de web. Puede ser configurado para hacer comprobaciones ligeras, medias o fuertes en un equipo o una red de equipos. Es una buena idea instalar SATAN y explorar tu equipo o red y arreglar los problemas que encuentres. Asegúrate de que la copia de SATAN la obtienes de metalab o de un FTP o sitio web con buena reputación. Hubo una copia troyana de SATAN que fue distribuída en la red. http://www.trouble.org/~zen/satan/satan.html. Ten en cuenta que SATAN no ha sido actualizado desde hace bastante tiempo y algunas de las otras herramientas de más abajo podrían funcionar mejor.
ISS (Internet Security Scanner) (Explorador de Seguridad de Internet) es otro explorador basado en el puerto. Es más rápido que Satan y por eso podría ser mejor para redes grandes. Sin embargo, SATAN tiende a proporcionar más información.
Abacus es un conjunto de herramientas para proveer seguridad y detección de intrusión basadas en el host. Mira su página inicial en la web para más información. http://www.psionic.com/abacus
SAINT es una versión actualizada de SATAN. Está basada en el web y tiene tests mucho más actualizados que SATAN. Puedes averiguar más sobre esto en: http://www.wwdsi.com/saint
Nessus es un explorador de seguridad gratuito. Tiene un interfaz gráfico GTK para facilitar el uso. También está diseñado con una configuración de enchufado muy agradable para hacer tests de exploración de nuevos puertos. Para más información, echa un vistazo a: http://www.nessus.org/
Detectar Exploraciones de Puerto
Hay algunas herramientas diseñadas para alertarte sobre sondeos mediante SATAN e ISS y otro software de exploración. Sin embargo, con el uso frecuente de los grapadores de tcp, y asegurándote de mirar en tus ficheros de log con regularidad, deberías ser capaz de notar tales sondeos. Incluso en la configuración más baja, SATAN aún deja huellas en los logs de un sistema Red Hat.
Hay también exploradores de puerto "clandestinos". Un paquete con el bit TCP ACK activado (como se hace con las conexiones establecidas) probablemente entrará a través de un cortafuegos de filtrado de paquetes. El paquete RST devuelto desde un puerto que _no haya establecido una sesión_ puede considerarse como prueba de que hay vida en ese puerto. Yo creo que los grapadores de TCP no detectarán esto.
sendmail, qmail y MTA
Uno de los servicios más importantes que puedes proporcionar es un servidor de correo. Desafortunadamente, también es uno de los más vulnerables a los ataques, simplemente debido a la cantidad de tareas que debe realizar y los privilegios que normalmente necesita.
Si estás usando sendmail es muy importante mantener las versiones actualizadas. sendmail tiene una historia muy larga de exploits de seguridad. Asegúrate de que siempre estás ejecutando la versión más reciente en http://www.sendmail.org/.
Recuerda que sendmail no tiene que estar ejecutándose para que puedas enviar correo. Si eres un usuario doméstico, puedes desactivar completamente sendmail y simplemente usar tu cliente de correo para enviar correo. Puedes también optar por remover el indicador "-bd" del fichero de inicio de sendmail, desactivando así las entradas de peticiones de correo. En otras palabras, puedes ejecutar sendmail desde el script de inicio usando lo siguiente: # /usr/lib/sendmail -q15m
Esto hará que sendmail limpie cada quince minutos la cola del correo con todos los mensajes que no pudieron entregarse con éxito al primer intento.
Muchos administradores optan por no usar sendmail y en su lugar eligen uno de los otros agentes de transporte de correo. Deberías considerar cambiarte a qmail. qmail fue diseñado desde los cimientos pensando en la seguridad. Es rápido, estable y seguro. Qmail puede encontrarse en http://www.qmail.org/
En competición directa con qmail está "postfix", escrito por Wietse Venema, el autor de tcp_wrappers y otras herramientas de seguridad. Anteriormente llamado vmailer, y patrocinado por IBM, éste es también un agente de transporte de correo escrito desde la base con la seguridad en mente. Puedes encontrar más información sobre vmailer en http://gulic.org/www.vmailer.org
Ataques de Negación de Servicio
Un ataque de "Negación de Servicio" ("Denial of Service") (DoS) es aquel en el que el atacante trata de mantener demasiado ocupado algún recurso para que no pueda responder a las peticiones legítimas o para denegar a los usuarios legítimos el acceso a tu equipo.
Los ataques DoS se han incrementado en los últimos años. Algunos de los más populares y recientes se listan debajo. Ten en cuenta que aparecen otros nuevos constantemente, de tal modo que estos sólo son unos pocos ejemplos. Lee las listas de seguridad de Linux y la lista y archivos de bugtraq para tener información más actual.
Inundación de SYN - La inundación de SYN es un ataque de denegación de servicio de red. Saca provecho de una "escapatoria" en el modo en que se crearon las conexiones TCP. Los núcleos más nuevos de Linux (2.0.30 en adelante) tienen diversas opciones configurables para impedir que los ataques de inundación de SYN denieguen a la gente el acceso a tu máquina o servicios. Ver Seguridad del núcleo para las opciones más adecuadas de protección de núcleo.
Fallo "F00F" de Pentium - Se descubrió recientemente que una serie de códigos de ensamble enviados a un procesador Pentium Intel genuíno reiniciaba el equipo. Esto afecta a todas las máquinas con procesador Pentium (no a los clones, ni a los Pentium Pro o PII), sin importar qué sistema operativo esté ejecutando. Los núcleos de Linux 2.0.32 y superiores contienen un trabajo acerca de este fallo, impidiendo que cierre tu máquina. El núcleo 2.0.33 tiene una versión mejorada del núcleo fix y se recomienda sobre el 2.0.32. Si estás funcionando sobre un Pentium, debes ponerte al día ¡ya!
Inundación de Ping - La inundación de Ping es un ataque simple de denegación de servicio por la fuerza bruta. El atacante envía una "riada" de paquetes ICMP a tu máquina. Si hace esto desde un host con mayor ancho de banda que el tuyo, tu equipo será incapaz de enviar nada a la red. Una variante de este ataque, llamado "smurfing", envía paquetes ICMP a un host con el retorno de IP de tu equipo, posibilitando que te inunden de forma menos detectable. Puedes encontrar más información sobre el ataque de "smurf" en http://www.quadrunner.com/~chuegen/smurf.txt
Si estás bajo un ataque de inundación de ping, usa una herramienta como tcpdump para determinar de dónde vienen los paquetes (o parece que vienen) y contacta luego con tu proveedor con esta información. Las inundaciones de ping pueden detenerse más fácilmente a nivel de enrutador o usando un cortafuegos.
Ping de la Muerte - El ataque Ping de la Muerte envía paquetes ICMP ECHO REQUEST que son demasiado grandes para encajar en las estructuras de datos del núcleo diseñadas para almacenarlos. Dado que enviar un sólo paquete "ping" grande (65,510 bytes) para muchos sistemas será causa de que se cuelguen o incluso se rompan, este problema fue rápidamente bautizado como el "Ping de la Muerte". Hace tiempo que ha sido arreglado y ya no es algo de lo que preocuparse.
Lágrima / Nuevo Lágrima - Uno de los más recientes exploits consiste en un fallo presente en el código de fragmentación IP en plataformas Linux y Windows. Se arregla en la versión 2.0.33 del núcleo y no requiere seleccionar alguna de las opciones de tiempo de compilación de núcleo para utilizar el arreglo. Linux aparentemente no es vulnerable al exploit "nueva lágrima".
Puedes econtrar un código para la mayoría de los exploits y una descripción más detallada de cómo funcionan en http://www.rootshell.com/ usando su motor de búsqueda.
Seguridad de NFS (Network File System).
NFS es un protocolo de compartición de ficheros muy ampliamente usado. Permite a los servidores ejecutar nfsd y mountd para "exportar" sistemas de ficheros completos a otras máquinas usando el soporte de sistema de ficheros NFS construído para sus núcleos (o usando algún otro soporte de cliente si no son máquinas Linux). mountd mantiene registro de los sistemas de ficheros montados en /etc/mtab y puede mostrarlos con showmount.
Muchos sitios usan NFS para servir directorios home a los usuarios, así que no importa a qué máquina del cluster se conecten, tendrán todos sus ficheros home.
Hay una pequeña cantidad de seguridad posible al exportar sistemas de archivos. Puedes hacer que tu nfsd haga un mapa del usuario de root remoto (uid=0) para el usuario nobody, denegándoles totalmente el acceso a los ficheros exportados. Sin embargo, dado que los usuarios individuales tienen acceso a sus propios ficheros (o al menos el mismo uid), el usuario root remoto puede registrar o hacer su a su cuenta y tener total acceso a sus ficheros. Esto es sólo un pequeño obstáculo para un atacante que tenga acceso a montar tus sistemas de archivo remoto.
Si tienes que usar NFS, asegúrate de que exportas sólo a aquellos equipos a los que realmente necesitas hacerlo. Nunca exportes tu directorio de root completo; exporta sólo los directorios que necesites exportar.
Ver el NFS COMO para más información sobre NFS, disponible en http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html
NIS (Network Information Service) (anteriormente YP).
El servicio de información de red (antes YP) es un medio de distribuir información a un grupo de equipos. El administrador de NIS mntiene las tablas de información y las convierte en archivos de mapas NIS. Después, estos mapas se sirven a la red, permitiendo a los equipos clientes del NIS obtener información sobre conexión, contraseña, directorio home y shell (toda la información en un fichero /etc/passwd estándar). Esto permite a los usuarios cambiar su contraseña una vez y que tenga efecto sobre todas los equipos en el dominio NIS.
NIS no es seguro en absoluto. Nunca se pretendió que lo fuese. Se pensó para que fuese manejable y útil. Cualquiera puede averiguar el nombre de tu dominio NIS (cualquiera en la red), puede obtener una copia de tu fichero passwd y usar "crack" y "John the Ripper" contra las contraseñas de tus usuarios. También, es posible engañar a NIS y hacer todo tipo de trucos sucios. Si tienes que usar NIS, asegúrate de que eres consciente de los peligros.
Hay un sustituto mucho más seguro para NIS, llamado NIS+. Mira en el NIS COMO para más información: http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html
Cortafuegos
Los cortafuegos son un medio de controlar a qué información se le permite entrar y salir de tu red local. Normalmente, el host cortafuegos está conectado a Internet y a tu LAN local, y el único acceso desde tu LAN a Internet es a través del cortafuegos. De este modo, el cortafuegos puede controlar lo que pasa en una u otra dirección entre Internet y tu LAN.
Hay muchos tipos de cortafuegos y de métodos de configurarlos. Los equipos Linux son muy buenos cortafuegos. El código del cortafuego puede construirse en los núcleos 2.0 y superiores. Las herramientas de modo usuario ipfwadm para núcleos 2.0, o ipchains para núcleos 2.2, te permiten cambiar, al vuelo, los tipos de tráfico de red que permites. También puedes registrar tipos particulares de tráfico de red.
Los cortafuegos son una técnica muy útil e importante para asegurar tu red. Sin embargo, no pienses que porque tienes un cortafuegos, no necesitas asegurar los equipos que están detrás de él. Esto es un error fatal. Mira el excelente Cortafuegos COMO en tu fichero metalab más reciente para más información sobre cortafuegos y Linux. http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
Más información también puede encontrarse en el Mini-cómo del Enmascaramiento de IP: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html
Más información en ipfwadm. La herramienta que te permite cambiar las configuraciones de tu cortafuegos, puede encontrarse en su página home: http://www.xos.nl/linux/ipfwadm/
Si no tienes experiencia con cortafuegos, y piensas instalar uno no sólo por una mera política de seguridad, es de obligatoria lectura el libro 'Firewalls' de O'Reilly y Associados u otro documento online sobre cortafuegos. Mira en http://www.ora.com/ para más información. El National Institute of Standards and Technology ha recopilado un documento excelente sobre cortafuegos. Aunque data de 1995, es aún bastante bueno. Puedes encontrarlo en http://csrc.nist.gov/nistpubs/800-10/main.html. También de interés son:
El Proyecto Freefire -- una lista de las herramientas de cortafuegos disponibles gratuitamente, que está en http://sites.inka.de/sites/lina/freefire-l/index_en.html
Diseño de Cortafuegos SunWorld -- escrito por los autores del libro de O'Reilly, proporciona una introducción tosca a los diferentes tipos de cortafuegos. Está disponible en http://www.sunworld.com/swol-01-1996/swol-01-firewall.html
8.11 Cadenas IP - Cortafuegos Linux para el Núcleo 2.2.x
Las Cadenas Cortafuegos IP de Linux es una actualización del código de cortafuegos de Linux 2.0 para el núcleo 2.2. Tiene una gran cantidad de características más que las implementaciones previas, incluyendo:
Manipulaciones más flexibles de paquetes.
Conteo más complejo.
Posibilidad de hacer cambios simples de política atómicamente.
Los fragmentos pueden ser explícitamente bloqueados, denegados, etc.
Registra paquetes sospechosos.
Puede manejar otros protocolos distintos a ICMP/TCP/UDP.
Si actualmente estás usando ipfwadm en el núcleo 2.0, hay scripts disponibles para convertir el formato del comando ipfwadm al formato que usa ipchains.
No dejes de leer el Cadenas IP COMO para más información. Está disponible en http://www.rustcorp.com/linux/ipchains/HOWTO.html
VPNs - Redes Privadas Virtuales
Las VPNs son una forma de establecer una red "virtual" por encima de una red ya existente. Esta red virtual a menudo está encriptada y el tráfico pasa sólo hacia y desde algunas entidades conocidas que se han unido a la red. Las VPNs se usan con frecuencia para conectar a alguien que trabaja en casa con la internet pública a la red interna de una compañía usando una red encriptada virtual.
Si estás ejecutando un cortafuegos de enmascaramiento de Linux y necesitas pasar paquetes de MS PPTP (producto punto a punto VPN de Microsoft), hay un parche del núcleo de linux para hacer esto. Ver: ip-masq-vpn.
Hay diversas soluciones VPN de Linux disponibles:
vpnd. Ver el http://www.crosswinds.net/nuremberg/~anstein/unix/vpnd.html.
Free S/Wan, disponible en http://www.xs4all.nl/~freeswan/
ssh puede usarse para construir una VPN. Ver el Mini-cómo de VPN para más información.
vps (servidor privado virtual) en http://www.strongcrypto.com/.
Ver también la sección sobre IPSEC para enlaces y más información.
Preparación de la Seguridad (antes de estar en-línea)
Vale, has probado tu sistema, has determinado que es tan seguro como factible y estás preparado para ponerlo online. Hay unas pocas cosas que deberías hacer ahora para prepararte para una intrusión, de forma que rápidamente puedas desactivar al intruso, obtener copias de seguridad y funcionar.
Hacer una Copia de Seguridad Completa de tu Equipo
La discusión de los métodos de respaldo y almacenaje está más allá del alcance de este documento, pero aquí van unas pocas palabras relativas a copias de respaldo y seguridad:
Si tienes menos de 650 Mb de datos para almacenar sobre una partición, una copia en CD-R de tus datos es un buen modo de proceder (es difícil de estropear después y si se almacena adecuadamente puede durar mucho tiempo). Las cintas y otros medios re-escribibles deben protegerse contra escritura en cuanto la copia de seguridad esté completa y después ser verificadas para impedir falsificación. Asegúrate de que almacenas tus copias de seguridad en un área segura desconectada de la línea. Una buena copia de seguridad te asegura un punto bien conocido desde el cual restaurar tu sistema.
9.2 Elegir un Buen Calendario de Copias de Seguridad
Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta para los viernes y una cinta para viernes impares. Realiza una copia de seguridad incremental cada día y una copia de seguridad completa en la cinta propia de los viernes. Si haces cambios particularmente importantes o añades datos importantes al sistema, sería adecuado una copia de seguridad completa.
Copia de Seguridad de tu RPM o Debian File Database
En el caso de una intrusión, puedes usar tu base de datos RPM como usarías tripwire, pero sólo si puedes asegurar también que no ha sido modificada. Debes copiar la base de datos RPM a un floppy, y mantener esta copia fuera de conexión en todo momento. La distribución Debian probablemente tiene algo similar.
Los ficheros /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm probablemente no quepan en un sólo floppy. Pero si se comprimen, cada uno por separado debería caber en un floppy.
Ahora, cuando tu sistema está comprometido, puedes usar el comando: root# rpm -Va
para verificar cada fichero del sistema. Ver la página rpm del manual, donde hay unas cuantas opciones que pueden incluirse para hacerlo menos verboso. No olvides que también debes estar seguro de que tu binario RPM no ha sido comprometido.
Esto significa que cada vez que se añade un nuevo RPM al sistema, la base de datos RPM necesitará ser rearchivada. Tendrás que decidir las ventajas frente a los inconvenientes.
LLevar Registro de los Datos de Contabilidad del Sistema
Es muy importante que la información que viene de syslog no haya sido comprometida. Un buen comienzo es hacer legibles y escribibles los ficheros en /var/log sólo para un número limitado de usuarios.
Asegúrate de echar un vistazo a lo que se obtiene escrito ahí, especialmente bajo la facilidad auth. Múltiples fallos de conexión, por ejemplo, pueden indicar un intento de asalto.
Dónde buscar tu fichero de log dependerá de tu distribución. En un sistema Linux que se conforma al "Linux Filesystem Standard", tal como Red Hat, habrá de buscarse en /var/log y comprobar messages, mail.log y otros.
Puedes averiguar hacia dónde está conectando tu distribución mirando en tu fichero /etc/syslog.conf. Éste es el fichero que le dice a syslogd (el demonio de conexión de sistema) dónde registrar los diversos mensajes.
Puedes también desear configurar tu script o demonio de rotación de registro para mantener los registros durante más tiempo, hasta que tengas tiempo de examinarlos. Echa un vistazo al paquete logrotate en las distribuciones recientes de Red Hat. Otras distribuciones probablemente tengan un procedimiento similar.
Si tus ficheros de log han sido estropeados, mira a ver si puedes determinar cuándo empezó el estropicio y que tipo de cosas parecen estar estropeadas. ¿Hay grandes períodos de tiempo de los que no puedes responder? Una buena idea es comprobar las cintas de seguridad (si tienes alguna) por si tienes ficheros de log no estropeados.
Los ficheros de log normalmente son modificados por el intruso para tapar sus huellas, pero aún así deben ser comprobados en busca de acontecimientos extraños. Puedes tener noticia de los intentos del intruso para lograr entrar, o de explotar un programa para obtener la cuenta del root. Podrías ver también registros de entradas antes de que el intruso tenga tiempo de modificarlas.
Debes asegurarte de separar la facilidad auth de otros datos de log, incluyendo los intentos de cambio de usuarios usando su, los intentos de conexión y otra información de contabilidad del usuario .
Si es posible, configura syslog para enviar una copia de los datos más importantes a un sistema seguro. Esto impedirá que un intruso encubra sus huellas borrando sus intentos de login/su/ftp/etc. Ver la página syslog.conf del manual y las referidas a la opción @.
Hay diversos programas syslogd más avanzados por ahí. Echa un vistazo a http://www.core-sdi.com/ssyslog/ para Secure Syslog. Secure Syslog te permite encriptar tus entradas syslog y asgurarte de que nadie las ha estropeado.
Otro syslogd con más características es syslog-ng. Te permite mucha más flexibilidad en tu logging y también puede tener tus flujos de syslog remoto para impedir las falsificaciones.
Finalmente, los ficheros de log son mucho menos útiles cuando nadie los lee. Tómate algún tiempo de vez en cuando para mirar tus ficheros de log y hazte una idea de qué pinta tienen en un día normal. Saber esto puede ayudar a notar las cosas inusuales.
Solicita todas las Nuevas Actualizaciones de Sistema.
La mayoría de los usuarios instalan Linux desde un CD-ROM. Debido a la naturaleza rápidamente cambiante de las mejoras de seguridad, siempre se están distribuyendo nuevos programas (mejorados). Antes de conectar tu máquina a la red, sería una buena idea revisar el sitio FTP de tu distribución y obtener todos los paquetes actualizados desde que recibiste el CD-ROM de tu distribución. Muchas veces estos paquetes contienen importantes mejoras de seguridad, por lo que es bueno tenerlos instalados.
Qué Hacer Durante y Después de una Ruptura
¿Has seguido algunos de los consejos dados aquí (o en otro sitio) y has detectado una ruptura? Lo primero que hay que hacer es mantener la calma. Las acciones precipitadas pueden causar más daño que el que haría el atacante.
Compromiso de Seguridad en marcha.
Descubrir un compromiso de seguridad que está en marcha puede ser una aventura tensa. La forma en la que reacciones puede tener grandes consecuencias.
Si el compromiso que estás viendo es físico, lo más probable es que hayas descubierto que alguien ha entrado en tu casa, oficina o laboratorio. Debes dar parte a las autoridades locales. En un laboratorio, podrías haber sorprendido a alguien intentando abrir una carcasa o reiniciar una máquina. Dependiendo de tu autoridad y procedimientos, podrías pedirle que parara o contactar con la gente de seguridad de tu local.
Si has detectado a un usuario local intentando comprometer tu seguridad, la primera cosa a hacer es confirmar que de hecho son quienes tú crees que son. Comprueba el sitio desde el cual se están conectando. ¿Es el sitio desde dónde normalmente se conectan? ¿No? Entonces usa un medio no-electrónico de darles un toque. Por ejemplo, llámalos por teléfono o dáte una vuelta por su oficina/casa y habla con ellos. Si confirman que están conectados, puedes pedirles que te expliquen qué estaban haciendo o pedirles que dejen de hacerlo. Si no están conectados, y no tienen ni idea de lo qué les estás diciendo, lo más probable es que este incidente requiera posterior investigación. Revisa tales incidentes y recoge un montón de información antes de hacer acusaciones.
Si has detectado un compromiso en la red, lo primero que hay que hacer (si eres capaz) es desconectar tu red. Si ellos están conectados vía modem, desenchufa el cable del modem; si están conectados vía ethernet, desenchufa el cable de Ethernet. Esto les impedirá hacer más daño y probablemente lo vean como un problema de la red y no como una detección.
Si eres incapaz de desconectar la red (si tienes un sitio ocupado o no tienes control físico de tus máquinas), el siguiente mejor paso es usar algo como tcp_wrappers o ipfwadm pare denegar el acceso desde el sitio del intruso.
Si no puedes denegar el acceso a toda la gente procedente del mismo sitio que el intruso, tendrás que cerrar la cuenta del usuario. Ten en cuenta que cerrar una cuenta no es cosa fácil. Tienes que tener en cuenta los ficheros .rhosts, el acceso de FTP y un montón de posibles puertas traseras.
Después de que hayas hecho algo de lo anterior (desconectado la red, denegado el acceso desde el sitio y/o desactivar su cuenta), necesitas cargarte todos sus procesos de usuario y desactivarlos.
Debes controlar bien tu sitio en los siguientes minutos, dado que el atacante intentará volver a entrar. Quizás usando una cuenta diferente y/o desde una dirección de red diferente.
El Compromiso de Seguridad ya ha ocurrido
Vale, o has detectado un compromiso que ya ha ocurrido o lo has detectado y (esperemos) has echado al atacante ofensivo fuera de tu sistema. ¿Ahora qué?
Cerrar el Agujero
Si eres capaz de determinar qué medios usó el atacante para entrar en tu sistema, debes intentar cerrar ese agujero. Por ejemplo, quizás tú ves varias entradas de FTP justo antes de que el usuario se conecte. Desactiva el servicio FTP y pruébalo y mira si hay una versión actualizada o si alguien de las listas sabe de una mejora.
Comprueba todos tus ficheros de log, haz una visita a tus listas y páginas de seguridad y mira si hay nuevos exploits comunes que puedas arreglar. Puedes encontrar las mejoras de seguridad de Caldera en http://www.caldera.com/tech-ref/security/. Red Hat no tiene todavía separadas sus mejoras de seguridad de sus mejoras de fallos, pero las erratas dla distribución están disponibles en http://www.redhat.com/errata
Ahora Debian tiene una lista de correo y una página web de seguridad. Ver: http://www.debian.com/security/ para más información.
Es muy probable que si un vendedor ha repartido una actualización de seguridad, la mayoría de los otros vendedores de Linux la tenga también.
Ahora hay un nuevo proyecto de auditar la seguridad de Linux. De forma metódica van pasando por todas las utilidades de espacio de usuario buscando posibles exploits y desbordamientos de seguridad. Dicen en su anuncio:
"Estamos intentando hacer una auditoría sistemática de las fuentes de Linux con vistas a que sea tan seguro como OpenBSD. Ya hemos descubierto (y mejorado) algunos problemas, pero más ayuda será bienvenida. La lista no está moderada y es también un recurso útil para discusiones generales de seguridad. La dirección de la lista es: security-audit@ferret.lmh.ox.ac.uk Para suscribirte, envía un correo-e a: security-audit-subscribe@ferret.lmh.ox.ac.uk"
Si no echas fuera al atacante, probablemente volverá. No sólo volverá a tu equipo, sino que volverá a cualquiera en tu red. Si estuviera ejecutando un husmeador de paquetes, hay muchas probabilidades de que tenga acceso a otras máquinas locales.
Evaluar el Daño
Lo primero es evaluar el daño. ¿Qué ha estado comprometido? Si estás ejecutando un Chequeo de Integridad como Tripwire, puedes usarlo para realizar una comprobación de integridad y te será de ayuda lo que te diga. Si no, tendrás que rebuscar en todos tus datos importantes.
Dado que los sistemas Linux están siendo cada vez más fáciles de instalar, podrías considerar salvar tus ficheros de configuración y luego limpiar tu(s) disco(s) y reinstalar, restaurando entonces tus ficheros de usuario y tus ficheros de configuración desde las copias de seguridad. Esto asegurará que tienes un sistema nuevo y limpio. Si tienes que hacer las copias de seguridad a partir del sistema comprometido, tienes que ser especialmente cuidadoso con todos los binarios que restaures, dado que pueden ser caballos troyanos puestos ahí por el intruso.
La re-instalación debe considerarse obligatoria cuando el intruso ha obtenido acceso de root. Además, querrás mantener cualquier evidencia que haya, por lo que puede tener sentido tener un disco libre en sitio seguro.
Luego tienes que preocuparte de cuánto tiempo hace que sucedió el compromiso y si las copias de seguridad mantienen algún trabajo dañado. Más sobre copias de seguridad en seguida.
¡Copias, Copias y Copias!
Tener regularmente copias de seguridad es una bendición en asuntos de seguridad. Si tu sistema está comprometido, puedes restaurar los datos que necesites a partir de las copias de seguridad. Por supuesto, algún dato es valioso también para el atacante y no lo destruirá, sino que lo robará y tendrá sus propias copias; pero al menos tú aún tienes los datos.
Debes comprobar las diversas copias de seguridad realizadas anteriormente antes de restaurar un fichero que ha sido estropeado. ¡¡¡El intruso podría haber comprometido tus ficheros hace mucho tiempo y puedes haber hecho con éxito muchas copias de seguridad de un fichero comprometido!!!
Desde luego, también las copias de respaldo conciernen a un montón de seguridad. Asegúrate de que las almacenas en un lugar seguro. Controla quién tiene acceso a ellas. (Si un atacante puede obtener tus copias de seguridad, puede tener acceso a todos tus datos sin que tú te enteres.)
Rastrear al Intruso.
Vale, has echado al intruso y recubierto tu sistema, pero aún no está todo hecho. Aunque es improbable que la mayoría de los intrusos sean atrapados, debes dar parte del ataque.
Debes informar del ataque al contacto de administración del sitio desde donde el atacante atacó tu sistema. Puedes mirar este contacto con whois o en la base de datos de Internic. Deberías enviarles un correo electrónico con todas las entradas de log aplicables y fechas y horas. Si descubriste cualquier otra cosa distintiva sobre el intruso, también deberías mencionar esto. Después de enviar el correo electrónico, podrías continuar (si así te parece) con una llamada telefónica. Si ese administrador a su vez descubre a tu atacante, podría hablar con el administrador del sitio desde donde viene y así sucesivamente.
Los buenos crackers a menudo usan muchos sistemas intermedios, algunos (o muchos) de los cuales incluso pueden no saber que han sido comprometidos. Tratar de rastrear a un cracker hasta su sistema home puede ser difícil. Ser amable con los administradores con los que hablas, puede ayudarte mucho para lograr ayuda por parte de ellos.
Debes también notificar a todas las organizaciones de seguridad a las que pertenezcas ( CERT o similares), así como al vendedor de tu sistema Linux.
Fuentes de Seguridad
Hay un MONTON de sitios buenos ahí fuera sobre la seguridad de Unix en general y la seguridad de Linux en particular. Es muy importante suscribirse a una (o más) de las listas de correo sobre seguridad y mantenerse al día en mejoras de seguridad. La mayoría de estas listas son de muy bajo volumen y muy informativas.
Sitios de FTP
CERT es el Equipo de Respuesta para Emergencias de Computadores (Computer Emergency Response Team). A veces envían alertas sobre ataques y mejoras actuales. Ver ftp://ftp.cert.org/ para más información.
Replay ( http://www.replay.com/) tiene archivos de muchos programas de seguridad. Dado que están fuera de los USA, no tienen que obedecer las restricciones sobre criptografía de los USA.
Matt Blaze es el autor de los CFS y un gran defensor de la seguridad. El archivo de Matt está disponible en ftp://ftp.research.att.com/pub/mab
tue.nl es un gran sitio FTP de seguridad en Holanda. ftp://ftp.win.tue.nl/pub/security/
Hay un conjunto de buenas herramientas para ayudar con la seguridad de la red y muchísimas de ellas vienen en las distribuciones de Linux.
Husmeadores de Paquetes
Una de las maneras más comunes por la que los intrusos logran acceder a más sistemas en tu red es empleando un husmeador de paquetes sobre un host ya comprometido. Este "husmeador" sólo escucha sobre el puerto Ethernet cosas como passwd y login y su que van en la corriente de paquetes y entonces registra el tráfico después de esto. De esta forma, los atacantes logran contraseñas para sistemas que aún no han intentado abordar. Las contraseñas de texto-claro son muy vulnerables a este ataque.
Ejemplo: El host A ha sido comprometido. El atacante instala un husmeador. El husmeador recoge las conexiones de administrador en el Host B desde el Host C. Logra la contraseña personal del administrador cuando conecta a B. Entonces, el administrador hace un su para arreglar el problema. Ahora ellos tienen la contraseña de root para el Host B. Más tarde el administrador deja a alguien hacer telnet desde su cuenta al Host Z en otro sitio. Ahora el atacante tiene una contraseña/conexión en el Host Z.
En este momento el atacante siquiera necesita comprometer un sistema para hacer esto: podría también meter un portátil o un pc en un edificio y pinchar en tu red.
Usar ssh u otros métodos de contraseña encriptada frustra este ataque. Cosas como APOP para cuentas POP también previenen este ataque. (Los logins POP normales son muy vulnerables a esto, como todo lo que envíe contraseñas en texto-claro por la red.)
Servicios de Sistema y Grapadores de tcp
Antes de poner tu sistema Linux en CUALQUIER red lo primero que tienes que mirar es qué servicios necesitas ofrecer. Los servicios que no necesites ofrecer deben ser desactivados para que tengas una cosa menos de la que preocuparte y los atacantes tengan un lugar menos en el que buscar un agujero.
Hay un montón de formas de desactivar servicios bajo Linux. Puedes mirar en tu fichero /etc/inetd.conf y ver qué servicios se están ofreciendo en tu inetd. Desactiva cualquiera que no necesites descomentándolos (# al principio de la línea), y luego envia tu proceso inetd a SIGHUP.
También puedes quitar (o descomentar) servicios en tu fichero /etc/services. Esto implicará que los clientes locales también serán incapaces de encontrar el servicio (p.e., si quitas ftp y tratas de hacer ftp a un sitio remoto desde esa máquina, fallará y te dará un mensaje de "servicio desconocido"). Normalmente no merece la pena quitar servicios, dado que no proporciona seguridad adicional. Si una persona local quiere usar ftp, incluso aunque tú lo hayas descomentado, haría que su propio cliente use el puerto común FTP y aún funcionaría mejor.
Algunos de los servicios que querrías dejar habilitados son:
ftp
telnet (o ssh)
mail, tal como pop-3 o imap
identd
Si sabes que no vas a usar algún paquete en particular, puedes borrarlo por completo. En la distribución Red Hat, rpm -e nombrepaquete borra el paquete entero. En la Debian dpkg --remove hace lo mismo.
Además, realmente deberías desactivar las utilidades rsh/rlogin/rcp, incluyendo login (usado por rlogin), shell (usado por rcp) y exec (usado por rsh) para que no se inicien en /etc/inetd.conf. Estos protocolos son extremadamente inseguros y han sido la causa de exploits en el pasado.
Debes comprobar tu /etc/rc.d/rcN.d, (donde N es el nivel de ejecución de tus sistemas) y ver si alguno de los servidores arrancados en ese directorio no se necesita. Los ficheros en /etc/rc.d/rcN.d son realmente enlaces simbólicos al directorio /etc/rc.d/init.d. Renombrar los ficheros en el directorio init.d tiene el efecto de inhabilitar todos los enlaces simbólicos en /etc/rc.d/rcN.d. Si sólo quieres deshabilitar un servicio para un nivel de ejecución particular, renombra el fichero apropiado sustituyendo la S mayúscula por una s minúscula, como esto: root# cd /etc/rc6.d root# mv S45dhcpd s45dhcpd
Si tienes ficheros estilo BSD rc, tienes que probar /etc/rc* para los programas que no necesites.
La mayoría de las distribuciones de Linux vienen con grapadores de tcp "grapando" todos tus servicios TCP. Un grapador de tcp (tcpd) se pide desde inetd en lugar del servidor real. Entonces tcpd chequea el host que está requiriendo el servicio y, o bien ejecuta el servidor real, o niega el acceso desde este host. tcpd te permite restringir el acceso a tus servicios TCP. Debes hacer un /etc/hosts.allow y añadir sólo aquellos hosts que necesiten tener acceso a los servicios de tu equipo.
Si eres un usuario telefónico doméstico, te sugerimos que niegues TODOS. tcpd también registra los intentos fallidos de acceder a servicios, así que esto te puede dar la alerta si te están atacando. Si añades nuevos servicios, debes asegurarte de configurarlos para usar grapadores de tcp si están basados en TCP. Por ejemplo, un usuario telefónico normal puede impedir a los extraños la conexión a su máquina, sin perder la capacidad de recuperar correo y hacer conexiones de red a Internet. Para hacer esto, debes añadir lo siguiente a tu /etc/hosts.allow:
ALL: 127.
Y por supuesto /etc/hosts.deny contendría:
ALL: ALL
que impedirá conexiones externas a tu máquina, pero permitiéndote desde el interior conectar a los servidores en Internet.
Ten en cuenta que los grapadores de tcp sólo protegen servicios ejecutados desde inetd y unos pocos otros selectos. Muy bien podría haber otros servicios ejecutándose en tu máquina. Puedes usar netstat -ta para encontrar una lista de todos los servicios que está ofreciendo tu máquina.
Verifica tu Información DNS
Mantener al día la información DNS sobre todos los hosts en tu red puede ayudar a incrementar la seguridad. Si un host no autorizado llega a conectarse a tu red, puedes reconocerlo por su carencia de una entrada DNS. Muchos servicios pueden estar configurados para no aceptar conexiones de hosts que no tienen entradas DNS válidas.
identd
identd es un pequeño programa que normalmente se ejecuta fuera de tu servidor inetd. Mantiene un registro de qué usuario está ejecutando qué servicio TCP, y luego informa de esto a quien se lo pregunta.
Mucha gente no entiende la utilidad de identd y por eso lo desactiva o bloquea todas las peticiones de sitios. identd no está para ayudar a sitios remotos. No hay modo de saber si el dato que obtienes del identd remoto es correcto o no. No hay autentificación en las peticiones de identd.
¿Por qué habrías de ejecutarlo entonces? Porque te ayuda, y es otro punto de datos para el seguimiento. Si tu identd no está comprometido, entonces sabes que está diciendo el nombre de usuario o uid de sitios remotos que usan los servicios TCP. Si el administrador de un sitio remoto te responde y te dice que el usuario tal-y-tal estaba tratando de hacer hack en su sitio, puedes fácilmente emprender una acción en contra de este usuario. Si no estás ejecutando identd, tendrás que mirar en montones y montones de registros de log, calcular quién estaba conectado en ese momento y, en general, gastar mucho más tiempo en rastrear al usuario.
El identd que viene con la mayoría de las distribuciones es más configurable de lo que mucha gente piensa. Puedes deshabilitarlo para usuarios específicos (ellos pueden hacer un fichero .noident), puedes registrar todas las solicitudes de identd (lo recomendamos), además puedes poner identd para que devuelva un uid en vez de un nombre de usuario o incluso NO-USER.
SATAN, ISS y Otros Exploradores de Red
Hay un conjunto de paquetes de software diferentes que hacen de puerto y dan servicio basados en la exploración de equipos o redes. SATAN, ISS, SAINT y Nessus son algunos de los más conocidos. Este software se conecta al equipo destino (o a todos los equipos destino en una red) en todos los puertos que puede, e intenta determinar qué servicio está ejecutándose ahí. Basado en esta información, puede decir si el equipo es vulnerable a un exploit específico en este servidor.
SATAN (Security Administrator's Tool for Analyzing Networks) (Herramienta de Administrador de Seguridad para Analizar Redes) es un explorador de puerto con una interfaz de web. Puede ser configurado para hacer comprobaciones ligeras, medias o fuertes en un equipo o una red de equipos. Es una buena idea instalar SATAN y explorar tu equipo o red y arreglar los problemas que encuentres. Asegúrate de que la copia de SATAN la obtienes de metalab o de un FTP o sitio web con buena reputación. Hubo una copia troyana de SATAN que fue distribuída en la red. http://www.trouble.org/~zen/satan/satan.html. Ten en cuenta que SATAN no ha sido actualizado desde hace bastante tiempo y algunas de las otras herramientas de más abajo podrían funcionar mejor.
ISS (Internet Security Scanner) (Explorador de Seguridad de Internet) es otro explorador basado en el puerto. Es más rápido que Satan y por eso podría ser mejor para redes grandes. Sin embargo, SATAN tiende a proporcionar más información.
Abacus es un conjunto de herramientas para proveer seguridad y detección de intrusión basadas en el host. Mira su página inicial en la web para más información. http://www.psionic.com/abacus
SAINT es una versión actualizada de SATAN. Está basada en el web y tiene tests mucho más actualizados que SATAN. Puedes averiguar más sobre esto en: http://www.wwdsi.com/saint
Nessus es un explorador de seguridad gratuito. Tiene un interfaz gráfico GTK para facilitar el uso. También está diseñado con una configuración de enchufado muy agradable para hacer tests de exploración de nuevos puertos. Para más información, echa un vistazo a: http://www.nessus.org/
Detectar Exploraciones de Puerto
Hay algunas herramientas diseñadas para alertarte sobre sondeos mediante SATAN e ISS y otro software de exploración. Sin embargo, con el uso frecuente de los grapadores de tcp, y asegurándote de mirar en tus ficheros de log con regularidad, deberías ser capaz de notar tales sondeos. Incluso en la configuración más baja, SATAN aún deja huellas en los logs de un sistema Red Hat.
Hay también exploradores de puerto "clandestinos". Un paquete con el bit TCP ACK activado (como se hace con las conexiones establecidas) probablemente entrará a través de un cortafuegos de filtrado de paquetes. El paquete RST devuelto desde un puerto que _no haya establecido una sesión_ puede considerarse como prueba de que hay vida en ese puerto. Yo creo que los grapadores de TCP no detectarán esto.
sendmail, qmail y MTA
Uno de los servicios más importantes que puedes proporcionar es un servidor de correo. Desafortunadamente, también es uno de los más vulnerables a los ataques, simplemente debido a la cantidad de tareas que debe realizar y los privilegios que normalmente necesita.
Si estás usando sendmail es muy importante mantener las versiones actualizadas. sendmail tiene una historia muy larga de exploits de seguridad. Asegúrate de que siempre estás ejecutando la versión más reciente en http://www.sendmail.org/.
Recuerda que sendmail no tiene que estar ejecutándose para que puedas enviar correo. Si eres un usuario doméstico, puedes desactivar completamente sendmail y simplemente usar tu cliente de correo para enviar correo. Puedes también optar por remover el indicador "-bd" del fichero de inicio de sendmail, desactivando así las entradas de peticiones de correo. En otras palabras, puedes ejecutar sendmail desde el script de inicio usando lo siguiente: # /usr/lib/sendmail -q15m
Esto hará que sendmail limpie cada quince minutos la cola del correo con todos los mensajes que no pudieron entregarse con éxito al primer intento.
Muchos administradores optan por no usar sendmail y en su lugar eligen uno de los otros agentes de transporte de correo. Deberías considerar cambiarte a qmail. qmail fue diseñado desde los cimientos pensando en la seguridad. Es rápido, estable y seguro. Qmail puede encontrarse en http://www.qmail.org/
En competición directa con qmail está "postfix", escrito por Wietse Venema, el autor de tcp_wrappers y otras herramientas de seguridad. Anteriormente llamado vmailer, y patrocinado por IBM, éste es también un agente de transporte de correo escrito desde la base con la seguridad en mente. Puedes encontrar más información sobre vmailer en http://gulic.org/www.vmailer.org
Ataques de Negación de Servicio
Un ataque de "Negación de Servicio" ("Denial of Service") (DoS) es aquel en el que el atacante trata de mantener demasiado ocupado algún recurso para que no pueda responder a las peticiones legítimas o para denegar a los usuarios legítimos el acceso a tu equipo.
Los ataques DoS se han incrementado en los últimos años. Algunos de los más populares y recientes se listan debajo. Ten en cuenta que aparecen otros nuevos constantemente, de tal modo que estos sólo son unos pocos ejemplos. Lee las listas de seguridad de Linux y la lista y archivos de bugtraq para tener información más actual.
Inundación de SYN - La inundación de SYN es un ataque de denegación de servicio de red. Saca provecho de una "escapatoria" en el modo en que se crearon las conexiones TCP. Los núcleos más nuevos de Linux (2.0.30 en adelante) tienen diversas opciones configurables para impedir que los ataques de inundación de SYN denieguen a la gente el acceso a tu máquina o servicios. Ver Seguridad del núcleo para las opciones más adecuadas de protección de núcleo.
Fallo "F00F" de Pentium - Se descubrió recientemente que una serie de códigos de ensamble enviados a un procesador Pentium Intel genuíno reiniciaba el equipo. Esto afecta a todas las máquinas con procesador Pentium (no a los clones, ni a los Pentium Pro o PII), sin importar qué sistema operativo esté ejecutando. Los núcleos de Linux 2.0.32 y superiores contienen un trabajo acerca de este fallo, impidiendo que cierre tu máquina. El núcleo 2.0.33 tiene una versión mejorada del núcleo fix y se recomienda sobre el 2.0.32. Si estás funcionando sobre un Pentium, debes ponerte al día ¡ya!
Inundación de Ping - La inundación de Ping es un ataque simple de denegación de servicio por la fuerza bruta. El atacante envía una "riada" de paquetes ICMP a tu máquina. Si hace esto desde un host con mayor ancho de banda que el tuyo, tu equipo será incapaz de enviar nada a la red. Una variante de este ataque, llamado "smurfing", envía paquetes ICMP a un host con el retorno de IP de tu equipo, posibilitando que te inunden de forma menos detectable. Puedes encontrar más información sobre el ataque de "smurf" en http://www.quadrunner.com/~chuegen/smurf.txt
Si estás bajo un ataque de inundación de ping, usa una herramienta como tcpdump para determinar de dónde vienen los paquetes (o parece que vienen) y contacta luego con tu proveedor con esta información. Las inundaciones de ping pueden detenerse más fácilmente a nivel de enrutador o usando un cortafuegos.
Ping de la Muerte - El ataque Ping de la Muerte envía paquetes ICMP ECHO REQUEST que son demasiado grandes para encajar en las estructuras de datos del núcleo diseñadas para almacenarlos. Dado que enviar un sólo paquete "ping" grande (65,510 bytes) para muchos sistemas será causa de que se cuelguen o incluso se rompan, este problema fue rápidamente bautizado como el "Ping de la Muerte". Hace tiempo que ha sido arreglado y ya no es algo de lo que preocuparse.
Lágrima / Nuevo Lágrima - Uno de los más recientes exploits consiste en un fallo presente en el código de fragmentación IP en plataformas Linux y Windows. Se arregla en la versión 2.0.33 del núcleo y no requiere seleccionar alguna de las opciones de tiempo de compilación de núcleo para utilizar el arreglo. Linux aparentemente no es vulnerable al exploit "nueva lágrima".
Puedes econtrar un código para la mayoría de los exploits y una descripción más detallada de cómo funcionan en http://www.rootshell.com/ usando su motor de búsqueda.
Seguridad de NFS (Network File System).
NFS es un protocolo de compartición de ficheros muy ampliamente usado. Permite a los servidores ejecutar nfsd y mountd para "exportar" sistemas de ficheros completos a otras máquinas usando el soporte de sistema de ficheros NFS construído para sus núcleos (o usando algún otro soporte de cliente si no son máquinas Linux). mountd mantiene registro de los sistemas de ficheros montados en /etc/mtab y puede mostrarlos con showmount.
Muchos sitios usan NFS para servir directorios home a los usuarios, así que no importa a qué máquina del cluster se conecten, tendrán todos sus ficheros home.
Hay una pequeña cantidad de seguridad posible al exportar sistemas de archivos. Puedes hacer que tu nfsd haga un mapa del usuario de root remoto (uid=0) para el usuario nobody, denegándoles totalmente el acceso a los ficheros exportados. Sin embargo, dado que los usuarios individuales tienen acceso a sus propios ficheros (o al menos el mismo uid), el usuario root remoto puede registrar o hacer su a su cuenta y tener total acceso a sus ficheros. Esto es sólo un pequeño obstáculo para un atacante que tenga acceso a montar tus sistemas de archivo remoto.
Si tienes que usar NFS, asegúrate de que exportas sólo a aquellos equipos a los que realmente necesitas hacerlo. Nunca exportes tu directorio de root completo; exporta sólo los directorios que necesites exportar.
Ver el NFS COMO para más información sobre NFS, disponible en http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html
NIS (Network Information Service) (anteriormente YP).
El servicio de información de red (antes YP) es un medio de distribuir información a un grupo de equipos. El administrador de NIS mntiene las tablas de información y las convierte en archivos de mapas NIS. Después, estos mapas se sirven a la red, permitiendo a los equipos clientes del NIS obtener información sobre conexión, contraseña, directorio home y shell (toda la información en un fichero /etc/passwd estándar). Esto permite a los usuarios cambiar su contraseña una vez y que tenga efecto sobre todas los equipos en el dominio NIS.
NIS no es seguro en absoluto. Nunca se pretendió que lo fuese. Se pensó para que fuese manejable y útil. Cualquiera puede averiguar el nombre de tu dominio NIS (cualquiera en la red), puede obtener una copia de tu fichero passwd y usar "crack" y "John the Ripper" contra las contraseñas de tus usuarios. También, es posible engañar a NIS y hacer todo tipo de trucos sucios. Si tienes que usar NIS, asegúrate de que eres consciente de los peligros.
Hay un sustituto mucho más seguro para NIS, llamado NIS+. Mira en el NIS COMO para más información: http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html
Cortafuegos
Los cortafuegos son un medio de controlar a qué información se le permite entrar y salir de tu red local. Normalmente, el host cortafuegos está conectado a Internet y a tu LAN local, y el único acceso desde tu LAN a Internet es a través del cortafuegos. De este modo, el cortafuegos puede controlar lo que pasa en una u otra dirección entre Internet y tu LAN.
Hay muchos tipos de cortafuegos y de métodos de configurarlos. Los equipos Linux son muy buenos cortafuegos. El código del cortafuego puede construirse en los núcleos 2.0 y superiores. Las herramientas de modo usuario ipfwadm para núcleos 2.0, o ipchains para núcleos 2.2, te permiten cambiar, al vuelo, los tipos de tráfico de red que permites. También puedes registrar tipos particulares de tráfico de red.
Los cortafuegos son una técnica muy útil e importante para asegurar tu red. Sin embargo, no pienses que porque tienes un cortafuegos, no necesitas asegurar los equipos que están detrás de él. Esto es un error fatal. Mira el excelente Cortafuegos COMO en tu fichero metalab más reciente para más información sobre cortafuegos y Linux. http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
Más información también puede encontrarse en el Mini-cómo del Enmascaramiento de IP: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html
Más información en ipfwadm. La herramienta que te permite cambiar las configuraciones de tu cortafuegos, puede encontrarse en su página home: http://www.xos.nl/linux/ipfwadm/
Si no tienes experiencia con cortafuegos, y piensas instalar uno no sólo por una mera política de seguridad, es de obligatoria lectura el libro 'Firewalls' de O'Reilly y Associados u otro documento online sobre cortafuegos. Mira en http://www.ora.com/ para más información. El National Institute of Standards and Technology ha recopilado un documento excelente sobre cortafuegos. Aunque data de 1995, es aún bastante bueno. Puedes encontrarlo en http://csrc.nist.gov/nistpubs/800-10/main.html. También de interés son:
El Proyecto Freefire -- una lista de las herramientas de cortafuegos disponibles gratuitamente, que está en http://sites.inka.de/sites/lina/freefire-l/index_en.html
Diseño de Cortafuegos SunWorld -- escrito por los autores del libro de O'Reilly, proporciona una introducción tosca a los diferentes tipos de cortafuegos. Está disponible en http://www.sunworld.com/swol-01-1996/swol-01-firewall.html
8.11 Cadenas IP - Cortafuegos Linux para el Núcleo 2.2.x
Las Cadenas Cortafuegos IP de Linux es una actualización del código de cortafuegos de Linux 2.0 para el núcleo 2.2. Tiene una gran cantidad de características más que las implementaciones previas, incluyendo:
Manipulaciones más flexibles de paquetes.
Conteo más complejo.
Posibilidad de hacer cambios simples de política atómicamente.
Los fragmentos pueden ser explícitamente bloqueados, denegados, etc.
Registra paquetes sospechosos.
Puede manejar otros protocolos distintos a ICMP/TCP/UDP.
Si actualmente estás usando ipfwadm en el núcleo 2.0, hay scripts disponibles para convertir el formato del comando ipfwadm al formato que usa ipchains.
No dejes de leer el Cadenas IP COMO para más información. Está disponible en http://www.rustcorp.com/linux/ipchains/HOWTO.html
VPNs - Redes Privadas Virtuales
Las VPNs son una forma de establecer una red "virtual" por encima de una red ya existente. Esta red virtual a menudo está encriptada y el tráfico pasa sólo hacia y desde algunas entidades conocidas que se han unido a la red. Las VPNs se usan con frecuencia para conectar a alguien que trabaja en casa con la internet pública a la red interna de una compañía usando una red encriptada virtual.
Si estás ejecutando un cortafuegos de enmascaramiento de Linux y necesitas pasar paquetes de MS PPTP (producto punto a punto VPN de Microsoft), hay un parche del núcleo de linux para hacer esto. Ver: ip-masq-vpn.
Hay diversas soluciones VPN de Linux disponibles:
vpnd. Ver el http://www.crosswinds.net/nuremberg/~anstein/unix/vpnd.html.
Free S/Wan, disponible en http://www.xs4all.nl/~freeswan/
ssh puede usarse para construir una VPN. Ver el Mini-cómo de VPN para más información.
vps (servidor privado virtual) en http://www.strongcrypto.com/.
Ver también la sección sobre IPSEC para enlaces y más información.
Preparación de la Seguridad (antes de estar en-línea)
Vale, has probado tu sistema, has determinado que es tan seguro como factible y estás preparado para ponerlo online. Hay unas pocas cosas que deberías hacer ahora para prepararte para una intrusión, de forma que rápidamente puedas desactivar al intruso, obtener copias de seguridad y funcionar.
Hacer una Copia de Seguridad Completa de tu Equipo
La discusión de los métodos de respaldo y almacenaje está más allá del alcance de este documento, pero aquí van unas pocas palabras relativas a copias de respaldo y seguridad:
Si tienes menos de 650 Mb de datos para almacenar sobre una partición, una copia en CD-R de tus datos es un buen modo de proceder (es difícil de estropear después y si se almacena adecuadamente puede durar mucho tiempo). Las cintas y otros medios re-escribibles deben protegerse contra escritura en cuanto la copia de seguridad esté completa y después ser verificadas para impedir falsificación. Asegúrate de que almacenas tus copias de seguridad en un área segura desconectada de la línea. Una buena copia de seguridad te asegura un punto bien conocido desde el cual restaurar tu sistema.
9.2 Elegir un Buen Calendario de Copias de Seguridad
Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta para los viernes y una cinta para viernes impares. Realiza una copia de seguridad incremental cada día y una copia de seguridad completa en la cinta propia de los viernes. Si haces cambios particularmente importantes o añades datos importantes al sistema, sería adecuado una copia de seguridad completa.
Copia de Seguridad de tu RPM o Debian File Database
En el caso de una intrusión, puedes usar tu base de datos RPM como usarías tripwire, pero sólo si puedes asegurar también que no ha sido modificada. Debes copiar la base de datos RPM a un floppy, y mantener esta copia fuera de conexión en todo momento. La distribución Debian probablemente tiene algo similar.
Los ficheros /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm probablemente no quepan en un sólo floppy. Pero si se comprimen, cada uno por separado debería caber en un floppy.
Ahora, cuando tu sistema está comprometido, puedes usar el comando: root# rpm -Va
para verificar cada fichero del sistema. Ver la página rpm del manual, donde hay unas cuantas opciones que pueden incluirse para hacerlo menos verboso. No olvides que también debes estar seguro de que tu binario RPM no ha sido comprometido.
Esto significa que cada vez que se añade un nuevo RPM al sistema, la base de datos RPM necesitará ser rearchivada. Tendrás que decidir las ventajas frente a los inconvenientes.
LLevar Registro de los Datos de Contabilidad del Sistema
Es muy importante que la información que viene de syslog no haya sido comprometida. Un buen comienzo es hacer legibles y escribibles los ficheros en /var/log sólo para un número limitado de usuarios.
Asegúrate de echar un vistazo a lo que se obtiene escrito ahí, especialmente bajo la facilidad auth. Múltiples fallos de conexión, por ejemplo, pueden indicar un intento de asalto.
Dónde buscar tu fichero de log dependerá de tu distribución. En un sistema Linux que se conforma al "Linux Filesystem Standard", tal como Red Hat, habrá de buscarse en /var/log y comprobar messages, mail.log y otros.
Puedes averiguar hacia dónde está conectando tu distribución mirando en tu fichero /etc/syslog.conf. Éste es el fichero que le dice a syslogd (el demonio de conexión de sistema) dónde registrar los diversos mensajes.
Puedes también desear configurar tu script o demonio de rotación de registro para mantener los registros durante más tiempo, hasta que tengas tiempo de examinarlos. Echa un vistazo al paquete logrotate en las distribuciones recientes de Red Hat. Otras distribuciones probablemente tengan un procedimiento similar.
Si tus ficheros de log han sido estropeados, mira a ver si puedes determinar cuándo empezó el estropicio y que tipo de cosas parecen estar estropeadas. ¿Hay grandes períodos de tiempo de los que no puedes responder? Una buena idea es comprobar las cintas de seguridad (si tienes alguna) por si tienes ficheros de log no estropeados.
Los ficheros de log normalmente son modificados por el intruso para tapar sus huellas, pero aún así deben ser comprobados en busca de acontecimientos extraños. Puedes tener noticia de los intentos del intruso para lograr entrar, o de explotar un programa para obtener la cuenta del root. Podrías ver también registros de entradas antes de que el intruso tenga tiempo de modificarlas.
Debes asegurarte de separar la facilidad auth de otros datos de log, incluyendo los intentos de cambio de usuarios usando su, los intentos de conexión y otra información de contabilidad del usuario .
Si es posible, configura syslog para enviar una copia de los datos más importantes a un sistema seguro. Esto impedirá que un intruso encubra sus huellas borrando sus intentos de login/su/ftp/etc. Ver la página syslog.conf del manual y las referidas a la opción @.
Hay diversos programas syslogd más avanzados por ahí. Echa un vistazo a http://www.core-sdi.com/ssyslog/ para Secure Syslog. Secure Syslog te permite encriptar tus entradas syslog y asgurarte de que nadie las ha estropeado.
Otro syslogd con más características es syslog-ng. Te permite mucha más flexibilidad en tu logging y también puede tener tus flujos de syslog remoto para impedir las falsificaciones.
Finalmente, los ficheros de log son mucho menos útiles cuando nadie los lee. Tómate algún tiempo de vez en cuando para mirar tus ficheros de log y hazte una idea de qué pinta tienen en un día normal. Saber esto puede ayudar a notar las cosas inusuales.
Solicita todas las Nuevas Actualizaciones de Sistema.
La mayoría de los usuarios instalan Linux desde un CD-ROM. Debido a la naturaleza rápidamente cambiante de las mejoras de seguridad, siempre se están distribuyendo nuevos programas (mejorados). Antes de conectar tu máquina a la red, sería una buena idea revisar el sitio FTP de tu distribución y obtener todos los paquetes actualizados desde que recibiste el CD-ROM de tu distribución. Muchas veces estos paquetes contienen importantes mejoras de seguridad, por lo que es bueno tenerlos instalados.
Qué Hacer Durante y Después de una Ruptura
¿Has seguido algunos de los consejos dados aquí (o en otro sitio) y has detectado una ruptura? Lo primero que hay que hacer es mantener la calma. Las acciones precipitadas pueden causar más daño que el que haría el atacante.
Compromiso de Seguridad en marcha.
Descubrir un compromiso de seguridad que está en marcha puede ser una aventura tensa. La forma en la que reacciones puede tener grandes consecuencias.
Si el compromiso que estás viendo es físico, lo más probable es que hayas descubierto que alguien ha entrado en tu casa, oficina o laboratorio. Debes dar parte a las autoridades locales. En un laboratorio, podrías haber sorprendido a alguien intentando abrir una carcasa o reiniciar una máquina. Dependiendo de tu autoridad y procedimientos, podrías pedirle que parara o contactar con la gente de seguridad de tu local.
Si has detectado a un usuario local intentando comprometer tu seguridad, la primera cosa a hacer es confirmar que de hecho son quienes tú crees que son. Comprueba el sitio desde el cual se están conectando. ¿Es el sitio desde dónde normalmente se conectan? ¿No? Entonces usa un medio no-electrónico de darles un toque. Por ejemplo, llámalos por teléfono o dáte una vuelta por su oficina/casa y habla con ellos. Si confirman que están conectados, puedes pedirles que te expliquen qué estaban haciendo o pedirles que dejen de hacerlo. Si no están conectados, y no tienen ni idea de lo qué les estás diciendo, lo más probable es que este incidente requiera posterior investigación. Revisa tales incidentes y recoge un montón de información antes de hacer acusaciones.
Si has detectado un compromiso en la red, lo primero que hay que hacer (si eres capaz) es desconectar tu red. Si ellos están conectados vía modem, desenchufa el cable del modem; si están conectados vía ethernet, desenchufa el cable de Ethernet. Esto les impedirá hacer más daño y probablemente lo vean como un problema de la red y no como una detección.
Si eres incapaz de desconectar la red (si tienes un sitio ocupado o no tienes control físico de tus máquinas), el siguiente mejor paso es usar algo como tcp_wrappers o ipfwadm pare denegar el acceso desde el sitio del intruso.
Si no puedes denegar el acceso a toda la gente procedente del mismo sitio que el intruso, tendrás que cerrar la cuenta del usuario. Ten en cuenta que cerrar una cuenta no es cosa fácil. Tienes que tener en cuenta los ficheros .rhosts, el acceso de FTP y un montón de posibles puertas traseras.
Después de que hayas hecho algo de lo anterior (desconectado la red, denegado el acceso desde el sitio y/o desactivar su cuenta), necesitas cargarte todos sus procesos de usuario y desactivarlos.
Debes controlar bien tu sitio en los siguientes minutos, dado que el atacante intentará volver a entrar. Quizás usando una cuenta diferente y/o desde una dirección de red diferente.
El Compromiso de Seguridad ya ha ocurrido
Vale, o has detectado un compromiso que ya ha ocurrido o lo has detectado y (esperemos) has echado al atacante ofensivo fuera de tu sistema. ¿Ahora qué?
Cerrar el Agujero
Si eres capaz de determinar qué medios usó el atacante para entrar en tu sistema, debes intentar cerrar ese agujero. Por ejemplo, quizás tú ves varias entradas de FTP justo antes de que el usuario se conecte. Desactiva el servicio FTP y pruébalo y mira si hay una versión actualizada o si alguien de las listas sabe de una mejora.
Comprueba todos tus ficheros de log, haz una visita a tus listas y páginas de seguridad y mira si hay nuevos exploits comunes que puedas arreglar. Puedes encontrar las mejoras de seguridad de Caldera en http://www.caldera.com/tech-ref/security/. Red Hat no tiene todavía separadas sus mejoras de seguridad de sus mejoras de fallos, pero las erratas dla distribución están disponibles en http://www.redhat.com/errata
Ahora Debian tiene una lista de correo y una página web de seguridad. Ver: http://www.debian.com/security/ para más información.
Es muy probable que si un vendedor ha repartido una actualización de seguridad, la mayoría de los otros vendedores de Linux la tenga también.
Ahora hay un nuevo proyecto de auditar la seguridad de Linux. De forma metódica van pasando por todas las utilidades de espacio de usuario buscando posibles exploits y desbordamientos de seguridad. Dicen en su anuncio:
"Estamos intentando hacer una auditoría sistemática de las fuentes de Linux con vistas a que sea tan seguro como OpenBSD. Ya hemos descubierto (y mejorado) algunos problemas, pero más ayuda será bienvenida. La lista no está moderada y es también un recurso útil para discusiones generales de seguridad. La dirección de la lista es: security-audit@ferret.lmh.ox.ac.uk Para suscribirte, envía un correo-e a: security-audit-subscribe@ferret.lmh.ox.ac.uk"
Si no echas fuera al atacante, probablemente volverá. No sólo volverá a tu equipo, sino que volverá a cualquiera en tu red. Si estuviera ejecutando un husmeador de paquetes, hay muchas probabilidades de que tenga acceso a otras máquinas locales.
Evaluar el Daño
Lo primero es evaluar el daño. ¿Qué ha estado comprometido? Si estás ejecutando un Chequeo de Integridad como Tripwire, puedes usarlo para realizar una comprobación de integridad y te será de ayuda lo que te diga. Si no, tendrás que rebuscar en todos tus datos importantes.
Dado que los sistemas Linux están siendo cada vez más fáciles de instalar, podrías considerar salvar tus ficheros de configuración y luego limpiar tu(s) disco(s) y reinstalar, restaurando entonces tus ficheros de usuario y tus ficheros de configuración desde las copias de seguridad. Esto asegurará que tienes un sistema nuevo y limpio. Si tienes que hacer las copias de seguridad a partir del sistema comprometido, tienes que ser especialmente cuidadoso con todos los binarios que restaures, dado que pueden ser caballos troyanos puestos ahí por el intruso.
La re-instalación debe considerarse obligatoria cuando el intruso ha obtenido acceso de root. Además, querrás mantener cualquier evidencia que haya, por lo que puede tener sentido tener un disco libre en sitio seguro.
Luego tienes que preocuparte de cuánto tiempo hace que sucedió el compromiso y si las copias de seguridad mantienen algún trabajo dañado. Más sobre copias de seguridad en seguida.
¡Copias, Copias y Copias!
Tener regularmente copias de seguridad es una bendición en asuntos de seguridad. Si tu sistema está comprometido, puedes restaurar los datos que necesites a partir de las copias de seguridad. Por supuesto, algún dato es valioso también para el atacante y no lo destruirá, sino que lo robará y tendrá sus propias copias; pero al menos tú aún tienes los datos.
Debes comprobar las diversas copias de seguridad realizadas anteriormente antes de restaurar un fichero que ha sido estropeado. ¡¡¡El intruso podría haber comprometido tus ficheros hace mucho tiempo y puedes haber hecho con éxito muchas copias de seguridad de un fichero comprometido!!!
Desde luego, también las copias de respaldo conciernen a un montón de seguridad. Asegúrate de que las almacenas en un lugar seguro. Controla quién tiene acceso a ellas. (Si un atacante puede obtener tus copias de seguridad, puede tener acceso a todos tus datos sin que tú te enteres.)
Rastrear al Intruso.
Vale, has echado al intruso y recubierto tu sistema, pero aún no está todo hecho. Aunque es improbable que la mayoría de los intrusos sean atrapados, debes dar parte del ataque.
Debes informar del ataque al contacto de administración del sitio desde donde el atacante atacó tu sistema. Puedes mirar este contacto con whois o en la base de datos de Internic. Deberías enviarles un correo electrónico con todas las entradas de log aplicables y fechas y horas. Si descubriste cualquier otra cosa distintiva sobre el intruso, también deberías mencionar esto. Después de enviar el correo electrónico, podrías continuar (si así te parece) con una llamada telefónica. Si ese administrador a su vez descubre a tu atacante, podría hablar con el administrador del sitio desde donde viene y así sucesivamente.
Los buenos crackers a menudo usan muchos sistemas intermedios, algunos (o muchos) de los cuales incluso pueden no saber que han sido comprometidos. Tratar de rastrear a un cracker hasta su sistema home puede ser difícil. Ser amable con los administradores con los que hablas, puede ayudarte mucho para lograr ayuda por parte de ellos.
Debes también notificar a todas las organizaciones de seguridad a las que pertenezcas ( CERT o similares), así como al vendedor de tu sistema Linux.
Fuentes de Seguridad
Hay un MONTON de sitios buenos ahí fuera sobre la seguridad de Unix en general y la seguridad de Linux en particular. Es muy importante suscribirse a una (o más) de las listas de correo sobre seguridad y mantenerse al día en mejoras de seguridad. La mayoría de estas listas son de muy bajo volumen y muy informativas.
Sitios de FTP
CERT es el Equipo de Respuesta para Emergencias de Computadores (Computer Emergency Response Team). A veces envían alertas sobre ataques y mejoras actuales. Ver ftp://ftp.cert.org/ para más información.
Replay ( http://www.replay.com/) tiene archivos de muchos programas de seguridad. Dado que están fuera de los USA, no tienen que obedecer las restricciones sobre criptografía de los USA.
Matt Blaze es el autor de los CFS y un gran defensor de la seguridad. El archivo de Matt está disponible en ftp://ftp.research.att.com/pub/mab
tue.nl es un gran sitio FTP de seguridad en Holanda. ftp://ftp.win.tue.nl/pub/security/
Suscribirse a:
Entradas (Atom)
