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.
Suscribirse a:
Entradas (Atom)
