Linux Security HOWTO <author>Kevin Fenzi, <tt>kevin@scrye.com</tt>&ero Dave Wreski, <tt>dave@nic.com</tt> Traducido por Pedro Pablo Fábrega <tt>pfabrega@arrakis.es</tt> <date>v0.9.11, 1 May 1998 <abstract> Este documento es una revisión general de las características de seguridad que tiene que tener en cuenta el administrador de un sistema Linux. Cubre la filosofía general de seguridad y cierto número de ejemplos específicos sobre como mejorar la seguridad de su sistema linux frente a intrusos. También se incluyen referencias sobre material y programas relacionados con la seguridad. OBSERVACIÓN: Esta es una versión beta del documento. Se agradecen las mejoras, críticas constructivas, añadidos y correcciones. Debido a mi filtro anti spam, necesitará una clave para enviarme correo. Lo siento. Para evitar esto incluya en la línea "subject" de su mensaje, "linux", "security" o "HOWTO". </abstract> <toc>  <sect> Introducción Este documento trata de cubrir parte de las principales características que afectan a la seguridad de linux. Se discutirán la filosofía general y los nuevos recursos de red. Otros COMOS se pueden solapar con ciertas características de seguridad, y esos han sido indicados donde se consideraba apropiado. Este documento no pretende ser una lista de actualización de programas que afectan a la seguridad (exploits). Continuamente aparecen programas de este tipo. Este documento le podrá indicar donde buscar una información actualizada de ese tipo, y algunos métodos generales para prevenir que esos programas tengan éxito.  <sect1> Nuevas versiones de este documento Las nuevas versiones de este documento se enviarán periódicamente a <it>comp.os.linux.answers</it>. También se añadir ftp anónimos que contienen información de este tipo, incluyendo: <tt> <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO" name="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO"> </tt> Además, normalmente podrá encontrar este documento en la página principal de Linux Worldwide Web mediante: <tt> <htmlurl url="http://sunsite.unc.edu/mdw/linux.html" name="http://sunsite.unc.edu/mdw/linux.html"> </tt> Finalmente, la última versión de este documento también debería estar disponible en varios formatos en: <tt> <htmlurl url="http://scrye.com/~kevin/lsh/" name="http://scrye.com/~kevin/lsh/"> </tt>  <sect1> Revisión Todos los comentarios, errores, información adicional y críticas de todo tipo se deberían dirigir a: <tt> <htmlurl url="mailto:kevin@scrye.com" name="kevin@scrye.com"> </tt> OBSERVACIÓN: Uso un filtro antispam para todo mi correo. Esto significa que si no lo conozco, su correo rebotará con una nota para que me lo reenvíe con una clave adecuada en la cabecera "subject". Comprendo el problema que esto ocasiona, pero desde que recibo entre 20 y 30 mensajes de spam diarios he tenido que hacer algo. Por favor, vuelva a enviar su mensaje con la clave en el campo subject y entonces leeré su correo. También puede evitar este paso estando seguro de poner "linux" "security" o "HOWTO" en el motivo ("subject") de su mensaje. <tt> <htmlurl url="http://scrye.com/~kevin/" name="http://scrye.com/~kevin/"> </tt>  <sect1> Descargo No se acepta ningún tipo de responsabilidad por los contenidos de este documento. Utilice los conceptos, ejemplos y otros contenidos bajo sus propios riesgo y responsabilidad. Adicionalmente, esta es una versión de las primeras, con muchas posibilidades de inexactitudes y errores. Cierto número de ejemplos y descripciones utilizan el esquema de la distribución RedHat(tm) y su sistema de configuración. En su distribución puede ser diferente. Hasta donde yo sé, sólo se describirán los programas, que bajo ciertas condiciones, pueden ser usados o evaluados para propósitos personales. La mayoría de los programas están disponibles de forma completa con las fuentes bajo términos parecidos a GNU.  <sect1> Información de Copyright Este documento es propiedad intelectual de (copyrighted) (c)1998 Kevin Fenzi y distribuido bajo las siguientes condiciones: <itemize> <item> Los documentos Linux HOWTO (COMO) se pueden reproducir y distribuir completos o en parte, por cualquier medio físico o electrónico, siempre que esta condición de copia se mantenga en todas las copias. La distribución comercial está permitida y fomentada; sin embargo al autor le gustaría que se le notificasen cualquiera de estas distribuciones. <item> Todas las traducciones, trabajos derivados o trabajos agregados tienen que estar cubiertos por esta nota de copyright. Esto es, NO puede realizar un trabajo derivado de un HOWTO (COMO) e imponer restricciones adicionales a su distribución. Se pueden ofrecer excepciones a estas reglas bajo ciertas condiciones; por favor póngase en contacto con el coordinador de HOWTO en la dirección de más abajo. <item> Si tiene alguna cuestión, por favor póngase en contacto con Greg Hankins, el coordinador de Linux HOWTO en </itemize> <tt> <htmlurl url="mailto:gregh@sunsite.unc.edu" name="gregh@sunsite.unc.edu"> </tt>   <sect1> ¿Por qué Necesitamos Seguridad? El cambio cotidiano del mundo de las comunicaciones de datos, las conexiones baratas a internet y el rápido desarrollo del software, la seguridad se está convirtiendo en una cuestión más y más importante. Ahora, la seguridad es un requisito básico, ya que la red global en insegura por definición. Mientras sus datos vayan del punto A al B por internet, por ejemplo, puede pasar por otros puntos durante el camino dando a otros usuarios la posibilidad de interceptarlos, e incluso alterar los datos. Incluso otros usuarios de su sistema pueden transformar datos de forma maliciosa para algo que no nos interese. Los intrusos, también conocidos como <it>crakers</it> pueden obtener acceso no autorizado usando unos conocimientos avanzados para hacerse pasar por vd. y robar su información e incluso denegarle el acceso a sus propios recursos. Si todavía se está preguntando la diferencia entre un <it>"Hacker"</it> y un <it>"Cracker"</it>, vea el documento de Eric Raymond, <it>"How to Become A Hacker"</it> (Como convertirse en un <it>Hacker</it>), disponible en <htmlurl url="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html" name="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html">.  <sect1> ¿Como de Seguro es Seguro? Primero, tenga en cuenta que ningún sistema es "completamente" seguro. Todo lo que puede hacer es aumentar la dificultad para que alguien pueda comprometer a su sistema. Para el conocimiento de los usuarios de Linux en casa, no se necesita demasiado para mantener alejados a los <it>crackers</it> casuales. Para los usuarios de Linux muy personallizados (bancos, compañías de telecomunicaciones, etc), se necesita mucho más trabajo. Otro factor a tener en cuenta es cuanto más seguro es su sistema más intrusiva se hace la seguridad. Necesita decidir donde está el equilibrio entre la facilidad de uso de su sistema y su seguridad. Por ejemplo, puede necesitar que cualquiera que llame por el módem a su sistema, nuestro módem tenga que devolver la llamada a su número de casa. Esto es más seguro, pero si alguien no está en casa, le hace más difícil conectarse. Podría poner su sistema Linux sin conexiones de red o a internet, pero esto le dificulta moverse por la web. Si es un sitio medio-grande, habrá establecido una "Política de Seguridad" que fije el nivel de seguridad que requiere ese sitio y que sistema de comprobación se realiza. Puede encontrar un ejemplo muy conocido de política de seguridad en <htmlurl url="http://ds.internic.net/rfc/rfc2196.txt" name="http://ds.internic.net/rfc/rfc2196.txt">. ha sido actualizado recientemente y contiene una gran estructura en la que basar la política de seguridad de su compañía.  <sect1> ¿Qué Está Tratando de Proteger? Antes de intentar asegurar su sistema debería determinar contra qué nivel de amenaza quiere protegerse, qué riesgo acepta o no y como resultado como de vulnerable es su sistema. Debería analizar su sistema para saber qué está protegiendo, por qué está protegiendo, qué valor tiene y quienes tienen responsabilidad de sus datos y otras cosas. <itemize><item> Riesgo es la posibilidad de que un intruso pueda intentar acceder con éxito a su equipo. ¿Puede un intruso leer y escribir en ficheros o ejecutar programas que puedan causar daño?¿Pueden borrar datos críticos? ¿Prevenir a su compañía de la pérdida de un trabajo importante realizado? Recuerde, alguien está que obteniendo acceso a su cuenta, o su sistema, también puede hacerse pasar por vd. Además, teniendo una cuenta insegura en su sistema, puede verse comprometida toda su red. Un simple usuario al que se le permita presentarse al sistema usando un fichero rhost, o permitir el uso de un servicio inseguro como tftp, origina el riesgo de que los intrusos puedan usarlo para "meter un puerta". Una vez que el intruso tiene una cuenta de usuario en su sistema, o en el sistema de cualquier otro, puede usarla para conseguir acceso a otros sistemas o a otras cuentas. <item> La amenaza proviene de alguien que tiene motivos para obtener acceso sin autorización a su red o equipo. Debe decidir en quien confía para tener acceso a su sistema y que amenaza puede representar. Las amenazas proceden de varios tipos de intrusos, y es útil tener en mente sus diferentes características cuando esté asegurando sus sistemas. <itemize> <item><bf>El Curioso</bf> - Este tipo de intruso está interesado básicamente interesado en qué tipo de sistema y datos tiene. </item> <item><bf>El Malicioso</bf> - Este tipo de intruso está fuera para bien hacerle caer su sistema, modificar su página web o cualquier otra cosa que le cueste tiempo y dinero recuperar. </item> <item><bf>El Intruso muy Personalizado</bf> - Este tipo de intruso trata de usar su sistema para ganar popularidad o mala fama. Puede usar su sistema para promocionar sus habilidades. </item> <item><bf>La Competencia</bf> - Este tipo de intruso está interesado en los datos que tiene en su sistema. Puede ser alguien que piense que tiene algo que le puede interesar financieramente o de otra forma. </item> </itemize><item> La vulnerabilidad describe como de bien protegido está su equipo frente a otra red, y el potencial para alguien que pueda obtener acceso no autorizado. ¿Qúe está en juego si alguien entra en su sistema? Desde luego será distinto para un usuario en casa con un enlace PPP dinámico que para las compañías que conectan su máquina a internet u otra gran red. ¿Cuanto tiempo me llevaría recuperar/recrear cualquier dato que se ha perdido? Una inversión en tiempo ahora puede ahorrar diez veces más de tiempo con posterioridad si tiene que recrear los datos que se perdieron. ¿Ha verificado su estrategia de copias de respaldo, y ha verificado sus datos últimamente? </itemize>  <sect1> Desarrollo de una Política de Seguridad Cree una política simple y genérica para su sistema, para que sus usuarios la puedan entender con facilidad y seguir. Esto debería proteger los datos que pretende poner a salvo y también la privacidad de sus usuarios. Algunos detalles que tiene que considerar adicionalmente quienes tienen acceso al sistema (¿pueden usar la cuenta mis amigos?), a quien se le permite instalar programas en el sistema, quien es el propietario de determinados datos, métodos de recuperación de pérdidas y uso apropiado del sistema. Una política de seguridad generalmente aceptada empieza con esta frase: <quote><bf>"Todo lo que no está permitido, está prohibido"</bf></quote> esto significa que, salvo que garantice acceso a un servicio para un usuario, el usuario no debería usar ese servicio hasta que no le ofrezca el acceso. Esté seguro de que las políticas funcionan en su cuenta regular de usuario, diciendo "Ah, no tengo permiso para resolver este problema, lo tendré que hacer como root", le puede llevar a descubrir agujeros de seguridad que son bastante obvios, e incluso otros que no han sido utilizados aun.  <sect1> Medios de la Seguridad de su Sitio Este documento discutirá varios medios mediante los cuales puede asegurar los recursos por los que tanto ha trabajado: su equipo local, datos, usuarios, red, incluso su reputación. ¿Qué sucedería con su reputación si un intruso borra los datos de uno de sus usuarios? ¿O alguien retoca sus páginas web? ¿O se publican los planes de su compañía para los próximos meses? Si está planeando una instalación de red hay muchos factores que debe tener en cuenta antes de añadir una simple máquina a su red. Incluso si tiene una simple cuenta telefónica PPP, o un pequeño sitio, esto no significa que los intrusos no estén interesados en sus sistemas. No sólo los sitios grandes y muy personalizados son los objetivos, muchos intrusos simplemente quieren explotar tantos sitios como les sea posible, sin importar su tamaño. Además, pueden usar agujeros de seguridad de su sitio para obtener accesos a otros sitios a los que vd. se conecte. Los intrusos tienen mucho tiempo a su disposición, y pueden evitar preguntarse como ha protegido su sistema con sólo intentar todas las posibilidades. Hay también varias razones más por las que un intruso puede estar interesado en su sistema, que se discutirá más tarde.  <sect2> Seguridad del Host Quizás el área donde se concentra más seguridad es en la seguridad basada en hosts. Típicamente implica estar seguro de que su sistema es seguro, y esperar que todas las demás personas de la red hagan lo mismo. Escoger buenas claves, asegurar los servicios de red de su host, mantener un buen registro de cuentas y actualizar los programas que tienen exploits conocidos que afectan a su seguridad, son las cosas de las que es responsable el administrador local. Aunque esto es absolutamente necesario, se puede convertir en una complicada labor si su red se hace muy grande.  <sect2> Seguridad de su Red La seguridad de la red es tan necesaria como la seguridad de un host. Con su simple sistema, o una red distribuida, internet o cientos, sino miles de equipos en la misma red, no puede tener la confianza de que todos esos equipos son seguros. Estando seguro de que sólo se le permite acceso a su red a usuarios autorizados, construyendo cortafuegos, usando cifrados fuertes, asegurándose de que no hay pícaros, o máquinas inseguras en su red, todo esto son parte de las preocupaciones y deberes del administrador de una red segura. Este documento discutirá alguna de las técnicas usadas para asegurar su sitio, y espero mostrar algunas formas para prevenir que un intruso obtenga acceso a lo que está tratando de proteger.  <sect2> Seguridad mediante Oscuridad Un tipo de seguridad que se debe discutir es "seguridad mediante oscuridad". Esto significa que haciendo algo como cambiar el nombre de conexión de 'root' a 'toor', por ejemplo, para intentar confundir a alguien que intenta entrar en sus sistema como root, es sólo una falsa sensación de seguridad, y puede originar unas consecuencias muy desagradables. Descanse seguro de que cualquier atacante de sistemas rápidamente se dará cuenta de esas mediadas de seguridad vacías. Por el hecho de que tenga un sitio pequeño o de relativamente bajo nivel de personalización, no significa que un intruso no esté interesado en lo que tiene. Discutiremos en próximas secciones lo que está protegiendo.   <sect> Visión General Este documento intentará explicar algunos procedimientos y programas usados con frecuencia para ayudar a mantener su sistema linux más seguro. Lo primero que tenemos que tener en mente es que no existe nada como un sistema completamente seguro. Todo lo que puede hacer es aumentar la dificultad para que alguien pueda comprometer su sistema. En el caso medio del usuario de linux en casa, no se requiere demasiado para mantener alejado al <it>cracker</it>. Para usuarios con grandes requisitos (bancos, compañías de telecomunicaciones, etc) se requiere mucho más trabajo. Otro factor a tener en cuenta es que cuanto más incremente la seguridad de su sistema, más intrusiva se vuelve la seguridad. Necesita decidir en que medida su sistema es utilizable y en que medida es seguro para sus propósitos. Por ejemplo, puede necesitar que cualquiera marque a su modem para que este devuelva la llamada a su casa. Esto es más seguro, pero si alguien no está en casa hace más difícil que se pueda conectar. También puede configurar su sistema linux sin conexión a internet, pero esto dificulta que pueda navegar por las webs. Si tiene un sitio medio-grande, debería establecer una "Política de Seguridad" que indique qué niveles requiere su sitio y qué medidas de evaluación se realizan. Este documento ha sido segregado en varias secciones. Contempla varios tipos de características de seguridad. El primero, seguridad física, contempla como tiene que proteger físicamente su máquina de ataques. El segundo describe como proteger su sistema del ataque de sus usuarios locales. El tercero, la seguridad en redes, describe como mejorar la seguridad de su sistema linux ante los ataques desde una red. El siguiente discute qué hacer cuando detecta que su sistema está siendo comprometido o ha detectado un recientemente. Después se enumeran una serie de enlaces hacia otros recursos de seguridad y por último una palabras de despedida. Los dos puntos principales de los que se tiene que dar cuenta cuando lea este documento son: <itemize> <item> Tenga cuidado con su sistema. Verifique los registros (logs) del sistema, tales como /var/log/messages y no pierda de vista su sistema , y <item> Dos, tenga su sistema actualizado, estando seguro de que ha instalado las versiones actuales de los programas y esté al tanto de las nuevas alertas de seguridad. Haciendo esto, le ayudará a hacer que su sistema sea mucho más seguro. </itemize>  <sect> Seguridad Física La primeras medida de seguridad que necesita tener en cuenta son las de seguridad física de sus sistemas. ¿Quien tiene acceso físico directo a su máquina? ¿Debería? ¿Puede proteger sus m sus ataques? ¿Debería protegerlas? El grado de seguridad física que necesita en su sistema depende en mucha medida de su situación, por supuesto. Si es un usuario doméstico probablemente no necesite demasiada protección, aunque le puede interesar proteger su máquina de un niño u otros problemas similares. Si está en un entorno de laboratorio o similar, necesitará un grado considerablemente mayor de seguridad, pero los usuarios necesitarán realizar y obtener el trabajo realizado en las máquinas. Muchas de las siguientes secciones nos ayudar Si está en una oficina, puede que necesite o no, mantener su máquina segura durante horas o mientras esté fuera. En algunas compañías, dejar su consola insegura puede ser motivo de despido. Obviamente los métodos de seguridad física tales como bloqueo de puertas, cables, o vigilancia por vídeo, son buenos métodos, pero no son para tratarlos en este documento. :)  <sect1> Bloqueo del equipo La mayoría de los PC modernos incluyen características de bloqueo. Normalmente habrá una cerradura en la caja que le permite, mediante una llave, ponerlo en posición de bloqueado o desbloqueado. En algunos casos puede prevenir la apertura de la caja y la manipulación del hardware. También puede ser una protección para que alguien arranque el equipo con su propio disquete u otro hardware. Estos bloqueos hacen diferentes cosas de acuerdo a las prestaciones de la placa base y de la fabricación de la caja. En muchos equipos hay que romper la caja para abrir el equipo. En otros, lo que hace es bloquear el teclado y el ratón de forma que no pueda teclear nada ni usar el ratón. Mire las prestaciones que le ofrece su placa base para tener más información. Esto puede ser útil en muchas ocasiones una característica útil, incluso cuando los cierres son de poca calidad y se pueden abrir con facilidad con un destornillador u otra herramienta. En algunos casos (de forma notable en sparcs y macs) tienen la posibilidad de ponerle un candado lo que dificulta notablemente el robo de su equipo.  <sect1> BIOS Security La BIOS es el nivel más bajo de seguridad mediante software que gestiona el hardware basado en los x86. LILO y otros métodos de arranque acceden a la BIOS para determinar como iniciar su máquina Linux. En otro hardware, bajo el que también funciona Linux tienen un software similar (OpenFirmware en macs y nuevos suns, sun boot prom, etc...). Puede usar la BIOS para prevenir que los atacantes reinicien su máquina y manipulen su sistema Linux. Muchas BIOS bajo linux/x86 le permiten incluir clave de acceso. Esto no proporciona excesiva seguridad (se puede reiniciar la BIOS o eliminar, si alguien abre la caja), pero puede ser otro elemento disuasorio (i.e. llevará más tiempo y dejará más pistas de la manipulación). Otras muchas BIOS de los x86 también le permiten especificar otras varias medidas de seguridad. Compruebe el manual de la BIOS o mire la próxima vez que reinicie el equipo. Algunos ejemplos son: desactivar reinicio desde el disquete, y claves para acceder a ciertas características de la BIOS. En Linux/Sparc, la eeprom SPARC se puede fijar para que solicite una clave en el arranque. Esto puede ralentizar el ataque. OBSERVACIÓN: Si tiene una máquina servidora, y tiene una clave para el arranque, la máquina no se reiniciará sin atención. Tenga en cuenta que necesitará acudir e introducir la clave en el caso de un corte de corriente. ;-(  <sect1> Seguridad en el arranque Los distintos cargadores de linux también tienen una clave de inicio. Si usa lilo, déle un vistazo a los parámetros "restricted" y "password". "password" le permite incluir una clave para la carga. "restricted" le permitir iniciar la máquina salvo que alguien especifique opciones en el indicador LILO: (como 'single'). Tenga en mente cuando configure todas estas claves que necesitará recordarlas. :) También recuerde que estas claves sólo ralentizan al atacante que tiene la deteterminación de hacerlo. Si alguien tiene información relativa a otros métodos diferentes de arranque, me gustaría oír de ellos. (grub, silo, milo, linload, etc). OBSERVACIÓN: NOTE: Si tiene una máquina servidora, y tiene una clave para el arranque, la máquina no se reiniciará sin atención. Tenga en cuenta que necesitará acudir e introducir la clave en el caso de un corte de corriente. ;-(  <sect1> xlock y vlock Si se aleja de su máquina de vez en cuando, estaría bien poder bloquear su consola para que nadie pueda manipularla o mirar su trabajo. Dos programas que hacen esto son xlock y vlock. Xlock blquea la pantalla. Se debería incluir en cualquier distribución de Linux que soporte X. Mire la página de manual para ver más, pero en general puede ejecutar xlock desde cualquier xterm de su consola y bloqueará la pantalla de forma que necesita su clave para desbloquearla. vlock es simple programita que le permite cerrar alguna o todas las consolas virtuales de su máquina linux. Puede bloquear sólo en la que está trabajando o todas. Si sólo cierra una, las otras se pueden abrir y utilizar la consola, pero no se podrá usar su vty hasta que no la desbloquee. vlock viene con RedHat, pero su situación puede ser diferente. Desde luego, bloquear una consola, prevendrá que alguien manipule su trabajo, pero no previene de reinicios de la máquina u otras formas de deteriorar su trabajo.  <sect1> Detección de problemas de seguridad física Lo primero que tiene que observar es cuando se reinició su máquina. Como Linux es un S.O. robusto y estable, las causas que le obligan a reiniciar el sistema es actualizar el S.O., el hardware o similares. Si su máquina se reinició sin que vd. lo sepa, cabe la posibilidad de un problema. Muchas de los métodos para comprometer la seguridad de su máquina requieren que el intruso reinicie o apague su máquina. Busque signos del ataque en la caja y por el área del ordenador. Aunque muchos intrusos borran las huellas de su presencia, es una buena idea comprobarlos y observar cualquier discrepancia. Algunas cosas para comprobar en sus registros (logs): <itemize> <item>Registros cortos o incompletos. <item>Registros con fecha y hora extraños. <item>Registros con permisos o propietarios incorrectos. <item>Registro de carga de reinicio del sistema o de otros servicios. <item>Registros perdidos. <item>Entradas su o logins desde lugares extraños. </itemize> Donde buscar los ficheros de registro, dependerá de su distribución. En RedHat estdrá que mirar en /var/log y comprobar messages, mail.log y otros. También le puede interesar configurar el guión (script) de rotación de registros o el demonio que mantiene los registros hasta un determinado tamaño para que le de tiempo a examinarlos. Échele un vistazo al paquete logrotate de las distribuciones recientes de RedHat. Otras distribuciones probablemente tendrán procesos similares.  <sect> Seguridad Local Lo siguiente que tiene que mirar es la seguridad de su sistema frente a los ataques de los usuarios locales. ¿Dije usuarios locales? Sí. Una de las primeras cosas que un intruso intenta es obtener acceso como usuario local. Con una seguridad local laxa, pueden "actualizar" su acceso normal como usuario a acceso como root utilizando una serie de deficiencias (bugs) y configuraciones pobres de los servicios locales. Si está seguro de su seguridad local, el intruso tendrá otro obstáculo que saltar. Los usuarios locales también pueden causar un montón de estragos con su sistema incluso (especialmente) si son realmente quienes dicen que son. Proporcionar cuentas a personas desconocidas o con las que no tiene información de contacto es muy mala idea. Antes de cambiar los permisos de cualquier sistema de ficheros, esté seguro de que entiende lo que está haciendo. Nunca cambie los permisos de un fichero sólo porque parezca una forma fácil de hacer que las cosas funcionen. Determine siempre por qué el fichero tiene ese permiso antes de cambiarlo.  <sect1> Creación de nuevas cuentas Debe estar seguro y proporcionar cuentas de usuario sólo con los requisitos mínimos para el trabajo. Si le crea una cuenta a su hijo, de 10 años, le puede interesar que sólo tenga acceso a un procesador de textos o un programa de dibujo, pero que no pueda hacer un rm de todo. Aquí tiene varias buenas reglas para cuando permita a otros un acceso legítimo a su máquina: <itemize> <item> Déle solo la mínima cantidad de privilegios que necesita. <item> Tega cuidado con donde/cuando se conecta o si se debería conectar. <item> Esté seguro de eliminar aquellas cuentas que ya no son necesarias. </itemize> Muchas de las cuentas de usuarios locales que se usan para comprometer la seguridad de su sistema, son las que no han sido utilizadas en meses o años. Como nadie las usa proporcionan el vehículo ideal para un ataque. <sect1> Seguridad del root Otro atacante local frecuente es el administrador del sistema linux. (Sí, vd.). Recuerde que sólo debe usar la cuenta de root para tareas específicas y cortas y el resto hacerlo como usuario normal. Ejecutar como root todo el tiempo es una idea muy muy mala. Use su o sudo para realizar las tareas que necesite. Varios trucos para evitar que pueda estropear su propio Linux como root: <itemize> <item> Cuando vaya a ejecutar un comando complejo, intente primero ejecutarlo de una forma no destructiva, especialmente los comandos con comodines. Por ejemplo, si quiere hacer un "rm foo*.bak", haga primero : "ls foo*.bak" y compruebe realmente los ficheros que va a borrar. También puede usar echo en algunas circunstancias. <item> Algunas personas encuentran útil hacer un "touch /-i" en sus sistemas Esto hará que comandos como "rm -rf *" le pregunten primero si realmente quiere borrar todos esos ficheros. ( Esto lo hace la shell, resolviendo primero el "-i" y tratándolo como la opción -i de rm). Esto no nos será útil con comandos rm sin *. <item> El comando path es importante para el usuario root. El comando path o la variable de entorno PATH define la busqueda de programas por la shell. Intente limitar tanto como sea posible el comando path para el usuario root, y nunca use '.', (directorio actual) en su PATH. Además, no tenga directorios con permiso de escritura en su ruta de búsquedas, ya que esto puede permitir a los atacantes modificar o poner nuevos binarios que se pueden ejecutar como root la próxima vez que ejecute el comando. <item> Nunca use la suit de herramientas rlogin/rsh/rexec (llamadas las r-utilidades) como as root. Puede ser objeto de diversos tipos de ataques y es peligroso ejecutarlas como root. Nunca cree un fichero .rhosts para root. <item> El fichero /etc/securetty contiene la lista de terminales desde las cuales se puede conectar el root. Por defecto (en Linux RedHat) se incluyen sólo las consolas virtuales (vtys). Tenga mucho cuidado al añadir otra cosa a este fichero. Debería poder presentarse al sistema de forma remota como un usuario normal u entonces usar su si lo necesita (mejor sobre ssh u otro canal cifrado) con lo cual no tiene necesidad de entrar directamente como root. <item> Cambie a root sólo para realizar tareas específicas simples. si tiene la necesidad de hacer algo, inténtelo en una shell de usuario normal hasta que esté <bf>seguro</bf> de qué hay que hacer como root. <item> Actúe de forma lenta y meditada cuando sea root. Sus acciones podrían afectar a un montón de cosas. ¡Piénselo antes de antes de teclear! </itemize> Si de forma inevitable tiene que permitir a alguien (espero que de mucha confianza) hacerse root en su máquina, hay algunas herramientas que le pueden ayudar. Sudo permite a los usuarios utilizar sus claves para acceder a un limitado número de comandos como root. Esto le permitiría, por ejemplo, permitir a un usuario montar y desmontar dispositivos removibles en su linux, pero sin tener otros privilegios. sudo también mantiene un registro de todos los intentos y éxitos, permite seguir la pista de los usuarios con los comandos y quor esta razón sudo funciona bien incluso en situaciones donde un determinado núemero de usariso tienen acceso de root, pero usan sudo para que se pueda tener un rastro de los cambios realizados.  <sect> Ficheros y Seguridad del Sistema de Archivos Unos pocos minutos de preparación y planificación antes de conectar su sistema le puede ayudar a proteger su sistema y los datos que tiene almacenados en él. <itemize> <item> No debería haber ninguna razón para que los directorios home de los usuarios permitieran que programas SUID/SGID se ejecutaran desde allí. Use la opción `nosuid' en /etc/fstab para las particiones que tienen permiso de escritura por alguien distinto de root. También le puede interesar usar `nodev' y `noexec' en las particiones de los directorios home de los usuarios. También en /var, lo que prohibe la ejecución de programas y creación dispositivos de bloque o carácter, que en ningún caso serían necesarios. <item> Si exporta sistemas de archivos vía NFS, esté seguro de configurar /etc/exports con los accesos lo más restrictivos posibles. Esto significa no usar plantillas, no permitir acceso de escritura a root y montar como sólo lectura siempre que sea posible. <item> Configura la máscara de creación de ficheros para que sea lo más restrictiva posible. Son habituales 022, 033, y la más restictiva 077, y añadirla a /etc/profile. <item> Ponga el límites al sistema de archivos en lugar de 'ilimitado' como está por defecto. Puede controlar el límite por usuario utilizando el módulo PAM de límite de recursos y /etc/pam.d/limits.conf. Por ejemplo, los límites para un grupo `users' podría parecer a esto: <tscreen><verb> @users hard core 0 @users hard nproc 50 @users hard rss 5000</verb></tscreen> Esto dice que se prohiba la creación de ficheros core, restringe el número de procesos a 50, y restringe el uso de memoria por usuario a 5M. <item> Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios de su sistema. Se debe mantener su integridad ya que determinan cuando y de donde entró en su sistema un usario o un potencial intruso. Los ficheros deberían tener los permisos 644, sin afectar a la normal operación del sistema. <item> El bit inmutable se puede usar para prevenir borrados accidentales o proteger un fichero para sobreescritura. También previene que alguien cree enlaces simbólicos a un fichero, que ha sido el origen de ataques basados en el borrados de los ficheros /etc/passwd o /etc/shadow. Vea la página del manual de chattr(1) para tener más información sobre el bit inmutable. <item> Los ficheros SUID y SGID de su sistema son potenciales riesgos de seguridad y deberían ser controlados. Como estos programas garantizan privilegios especiales al usuario que los ejecuta, es necesario estar seguro que no hay instalados programas inseguros. Un truco favorito de los crackers es explotar programas con el bit SUID, y entonces dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso aunque el agujero original ya esté tapado. Encuentre todos los programas SUID/SGID de su sistema y mantener la pista de lo que son, para que esté prevenido de cualquier cambio que podría indicar un potencial intruso. Use el siguiente comando para localizar todos los progrmas SUID/SGID en su sistema: <tscreen><verb> root# find / -type f \( -perm -04000 -o -perm -02000 \) </verb></tscreen> Puede eliminar los permisos SUID o SGIG de un programa con chmod(1), y siempre puede devolverlo a su estado original si piensa que es absolutamente necesario. <item> Los ficheros con permiso de escritura global, particularmente los del sistema, pueden ser un agujero de seguridad si un cracker obtiene acceso a su sistema y los modifica. Además los directorios con permiso de escritura global son peligrosos ya que permiten a un cracker añadir y borrar los ficheros que quiera. Para localizar los ficheros con permiso de escritura global, use el siguiente comando: <tscreen><verb> root# find / -perm -2 -print </verb></tscreen> y esté seguro de saber por qué tienen esos permisos de escritura. En el curso normal de una operación ficheros tendrán permisos de escritura, incluidos algunos de /dev y enlaces simbólicos. <item> Los ficheros sin propietario también pueden ser un indicio de que un intruso ha accedido a su sistema. Puede localizar los ficheros de su sistema que no tienen propietario o que no pertenecen a un grupo con el comando: <tscreen><verb> root# find / -nouser -o -nogroup -print </verb></tscreen> <item> La localización de ficheros .rhosts debería ser una de los deberes de la administración de su sistema regular, ya que estos ficheros no se deberían permitir en sus sistema. Recuerde que un cracker sólo necesita una cuenta insegura para potencialmente obtener acceso a toda su red. Puede localizar todos los ficheros .rhosts de su sistema con el siguiente comando: <tscreen><verb> root# find /home -name .rhosts -print </verb></tscreen> <item> Finalmente, antes de cambiar permisos en cualquier sistema de ficheros, esté seguro de que entiende lo que hace. Nunca cambie permisos de un fichero simplemente porque parezca la forma fácil de hacer una cosa. Siempre debe determinar porqué el fichero tiene esos permisos antes de modificarlos. </itemize>  <sect1>Estado de umask El comando umask se puede usar para determinar el modo de creación de ficheros por defecto en su sistema. Es el complemento octal a los modos de fichero deseado. Si los ficheros se crean sin ningún miramiento de estado de permisos, el usuario, de forma inadvertida podrá asignar permisos de lectura o escritura a alguien que no debería tenerlo. De forma típica, el estado de umask incluye 022, 027 y 077, qque es lo más restrictivo. Normalmente umask se pone en /etc/profile y por tanto se aplica a todos los usuarios del sistema. Por ejemplo, puede tener una línea parecida a la siguiente: <tscreen><verb> # Pone el valor por defecto de umask del usuario umask 033 </verb></tscreen> Esté seguro de que el valor umask de root es 077, lo cual desactiva los permisos de lectura, escritura y ejecución para otros usuarios, salvo que explícitamente use chmod(1). Si está usando Red Hat, y se adhiere a su esquema de creación de ID de grupos y usuarios (User Private Groups), sólo es necesario usar 002 para umask. Esto se debe al hecho de que la configuración por defecto incluye un grupo por usuario.   <sect1> Permisos de ficheros Es importante asegurarse que sus ficheros de sistema no los abren los usuarios o grupos que no tienen que realizar tareas de mantenimiento del sistema por ediciones casuales. UNIX separael control de acceso a ficheros y directorios de acuerdo con tres características: propietario, grupo y otros. Siempre hay un sólo propietario, todos los miembros del grupo y cualquier otro. Una rápida explicación de los permisos Unix: Propiedad: -Qué usuario(s) y grupo(s) retiene el control de los permisos del nodo y del padre del nodo. Permisos - Bits que se pueden fijar para permitir ciertos tipos de acceso a él. Los permisos para directorio pueden tener un significado diferente a los permisos para ficheros. Lectura (r): <itemize> <item>Poder ver los contenidos de un fichero <item>Poder leer un directorio </itemize> Escritura (w): <itemize> <item>Poder modificar o añadirle a un fichero <item>Poder borrar o mover ficheros en un directorio </itemize> Ejecución(x): <itemize> <item>Poder ejecutar un programa binario <item>Poder buscar en un directorio </itemize> Usted - El propietario del fichero Group - El grupo al que pertenece Everyone - Cualquiera del sistema <descrip> <tag/Save Text Attribute: (Para directorios)/ El sticky bit también tiene un significado diferente cuando se aplica a directorios. Si es sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son propiedad del usuario o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios. </descrip> <descrip> <tag/Attributo SUID: (Para Ficheros)/ Este describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso (no el usuario que lo lanza). Esto es causa de la utilización de muchos 'buffer overflow'. </descrip> <descrip> <tag/Atributo SGID: (Para ficheros)/ Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto. </descrip> <descrip> <tag/Atributo SGID: (Para directorios)/ Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio. </descrip> Usted - El propietario del fichero Grupo - El grupo al que vd. pertenece Otros - Cualquiera del sistema que no sea propietario o miembro del grupo. <tscreen><verb> Ejemplos: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - ¿directorio? (no) 2nd bit - ¿lectura por el propietario? (si, por kevin) 3rd bit - por el propietario? (si, por kevin) 4th bit - ¿ejecución por el propietario? (no) 5th bit - ¿lectura por el grupo? (sí, por users) 6th bit - ¿escritura por el grupo? (no) 7th bit - ¿ejecución por el grupo? (no) 8th bit - ¿lectura por cualquiera? (si, por cualquiera) 9th bit - ¿escritura por cualquiera? (no) 10th bit - ¿ejecución por cualquiera? (no) </verb></tscreen> Las siguientes líneas son ejemplos del conjunto mínimo de permisos que se requieren para llevar a cabo el acceso descrito. Puede querer dar más permisos que los listados, pero esto debería describir que hacen esos permisos mínimos sobre los ficheros: <tscreen><verb> -r-------- Permite acceso de lectura al propietario --w------- Permite al propietario modificar o borrar el fichero ---x------ El propietario puede ejecutar este programa, pero no scripts de shell que requieren permisos de lectura ---s------ Se ejecutará con usuario efectivo ID = propietario -------s-- Se ejecutará con usuario efectivo ID = grupo -rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap) ---t------ No tiene efecto. (antes sticky bit) </verb></tscreen> <bf>Ejemplo de Directorio:</bf> <tscreen><verb> drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - ¿directorio? (si, contiene muchos ficheros) 2nd bit - ¿lectura por el propietario? (si, por kevin) 3rd bit - por el propietario? (si, por kevin) 4th bit - ¿ejecución por el propietario? (sí, por kevin) 5th bit - ¿lectura por el grupo? (sí, por users) 6th bit - ¿escritura por el grupo? (no) 7th bit - ¿ejecución por el grupo? (sí, por users) 8th bit - ¿lectura por cualquiera? (si, por cualquiera) 9th bit - ¿escritura por cualquiera? (no) 10th bit - ¿ejecución por cualquiera? (sí, por cualquiera) </verb></tscreen>  </verb></tscreen> Las siguientes líneas son ejemplos del mínimo conjunto de permisos que se requieren para llevar a cabo el acceso descrito. Le puede interesar dar más permisos que los indicados, pero esto debería describir que hacen los permisos mínimos en los directorios: <tscreen><verb> dr-------- El contenido se puede listar pero no se pueden leer los atributos. d--x------ Se puede entrar en el directiorio y usado en las rutas de ejecución completas. dr-x------ Se pueden leer los atributos del fichero por el propietario. d-wx------ Se pueden crear/borra ficheros, incluso si no es el actual. d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp d---s--s-- No tiene efecto </verb></tscreen> Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca deje algún fichero del sistema con permiso de escritura por un grupo o por cualquiera. Algunos ficheros de configuración, incluyendo, /etc/shadow, sólo deberían tener permiso de lectura por root, y los directorios de /etc no deberías ser accesibles, al menos por otros. <descrip> <tag /SUID Shell Scripts/ Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razón el núcleo no los acepta. Sin importar lo seguro que piense que es su script de shell, puede ser utilizado para que un cracker pueda obtener acceso a una shell de root. </descrip>  <sect1> Verificar la integridad con Tripwire Una forma cómoda de detectar ataques locales (y también de red) en sus sistema es ejecutar un programa que verifique la integridad como Tripwire. Tripwire ejecuta varios cheksums de todos los binarios importantes y ficheros de configuración y los compara con una base de datos con valores de referencia aceptados como buenos. Así se detecta cualquier cambio en los ficheros. Es buena idea instalar tripwire en un disquete y protegerlo físicamente. De esta forma no se puede alterar tripwire o modificar su base de datos. Una vez que tripwire se ha configurado, es buena idea ejecutarlo como parte de de los deberes habituales de administración para ver si algo ha cambiado. Incluso puede añadir una entrada a crontab para ejecutar tripwire desde su disquete todas las noches y enviar por correo los resultados y verlos por la mañana, Algo como esto: <tscreen><verb> # set mailto MAILTO=kevin # run tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire </verb></tscreen> le enviará por correo un informe cada mañana a las 5:15am. Tripwire puede ser un "don divino" para detectar intrusos antes de que tenga otro tipo de noticias de ellos. Como son muchos los ficheros que se modifican en su sistema, debería tener cuidado con lo que es la actividad de un cracker y lo que es la activiadad normal del sistema.  <sect1> Caballos de Troya El nombre de Caballo de Troya se debe al símil que se establece con los hechos contados por Homero en la Iliada. La idea es poner un programa binario, que parece genial, y consigue que otras personas lo carguen y lo ejecuten como root. Entonces puede comprometer la seguridad de su sistema mientras no se presta atención. Mientras se piensa que el binario que hemos lanzado hace algo (que puede estar bien), también puede estar saltándose la seguridad. Debería tener cuidado con qué programas instala en su máquina. Redhat proporciona md5 checksums y ficheros firmados con pgp para pueda verificar que está instalando algo real. Otras distribuciones disponen de métodos similares. Jamás debería ejecutar un binario del cual no tiene las fuentes o sabe perfectamente qué programa es. Algunos atacantes también están publicando código fuente para que se pueda realizar un uso público y aprovecharse de ello. Aunque esto puede ser complicado, debería asegurarse que obtiene las fuentes de un programa de el sitio real de su distribución. Si el programa se va a ejecutar como root, tendría que estar seguro que alguien de su confianza ha revisado y verificado el programa.  <sect1> Seguridad de Claves & y Cifrado (Encryption) Unas de las más importantes características de seguridad usadas hoy son ls claves. Es importante para todos, usted y sus usuarios, tener claves seguras insospechadas. La mayoría de las distribuciones Linux recientes incluyen programas 'passwd' que no permiten a los usuarios poner claves fácilmente adivinables. Esté seguro de que su programa passwd está actualizado y tiene estas características. Está fuera de los objetivos de este documento una discusión en profundidad sobre cifrado, pero daremos una introducción. El cifrado (encriptado) es muy útil, posiblemente incluso necesario en estos días. Hay distintos métodos de cifrar datos, cada uno con sus propios inconvenientes. Debería estar prevenido con algunos de los más comunes. cifrado de claves unix: La mayoría de los unix (y linux no es una excepción) usan DES (Data Encryption Standard) para cifrar sus claves. Estas claves cifradas se almacenan (típicamente) en /etc/passwd o (con menos frecuencia ) en /etc/shadow. Cuando intenta presentarse al sistema, todo lo que teclea se cifra de nuevo y comparado con la entrada correspondiente del fichero /etc/passwd. Si coinciden, debe ser la misma clave y se le permite el acceso. DES en un algoritmo de cifrado de una sola vía. DES tiene reputación de débil en estos días de ordenadores rápidos. Ataques a la fuerza bruta, como crack o John de ripper (ver abajo), con frecuencia pueden adivinar claves salvo que su clave sea lo suficientemente aleatoria. Los módulos PAM (ver abajo) permiten usar rutinas de cifrado diferentes con sus claves (MD5 o parecidas).  <sect1> PGP y Clave de Cifrado Pública (Public Key Cryptography) Public Key Cryptography, tal y como se usa por PGP, implica un cifrado que usa una clave para cifrar y otra para descifrar. Tradicionalmente, el cifrado implica el uso de la misma clave para descifrar que la que se usó para cifrar. Esta "clave privada" se debe conocer por ambas partes y de alguna forma, transferirse de uno a otro de forma segura. La clave de cifrado pública alivia la necesidad de asegurar la transmisión de la clave usada para el cifrado usando dos claves separadas, una pública y otra privada. Cada clave pública de una persona está disponible por cualquiera para realizar el cifrado, mientras que a la misma vez cada persona mantiene su clave privada para descifrar el mensaje cifrado con la correspondiente clave pública. Hay ventajas con las claves de cifrado públicas y privadas y puede informarse de las diferencias en las FAQ de RSA Cryptography indicadas al final de esta sección. PGP (Pretty Good Privacy) está muy bien soportada por Linux. Las versions 2.6.2 y 5.0 se sabe que funcionan bien. Para iniciarse en PGP y como usarlo mire las PGP FAQ. <htmlurl url="http://www.pgp.com/service/export/faq/55faq.cgi" name="http://www.pgp.com/service/export/faq/55faq.cgi"> Esté seguro de usar la versión que es aplicable a su país, ya que debido a las restricciones del gobierno de EE.UU, los cifrados fuertes se consideran armas militares y se prohibe su transferencia electrónica fuera del país. También hay una guía paso a paso para configurar PGP en Linux, disponible en <htmlurl url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html" name="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"> Fue escrito para la versión Internacional de PGP. (pero es fácilmente adaptable a la versión EE.UU). Puede que necesite un parche para alguna de las últimas versiones de Linux, disponible en <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/crypto" name="ftp://sunsite.unc.edu/pub/Linux/apps/crypto">. Podemos encontrar más indormación sobre cifrado en RSA cryptography FAQ, disponibles en <htmlurl url="http://www.rsa.com/rsalabs/newfaq/" name="http://www.rsa.com/rsalabs/newfaq/">. Aquí encontrará información sobre términos como "Diffie-Hellman", "public-key cryptography", "Digital Certificates", etc.  <sect1> SSL, S-HTTP, HTTPS y S/MIME Con frecuencia los usuario preguntan las diferencias entre los distintos protocolos de seguridad y cifrado, y como se usan. Como esto no es un documento sobre cifrdo, es buena idea explicar brevemente qué es cada cosa y donde encontrar más información. <itemize> <item><bf>SSL:</bf> - SSL, o Secure Sockets Layer, es un método de cifrado desarrollado por Netscape para proporcionar seguridad en Internet. Soporta varios protocolos diferentes de cifrado y proporciona un servidor de verificación de clientes. SSL funciona a nivel de transporte, creando un canal seguro de datos cifrados y así puede cifrar datos de diversos tipos. Esto se ve con frecuencia cuando vamos a un sitio seguro para ver documentación en línea con Comunicatos y sirve como base para comunicaciones seguras con Comunicator, también como muchos Se puede encontrar más información en <htmlurl url="http://www.consensus.com/security/ssl-talk-faq.html" name="http://www.consensus.com/security/ssl-talk-faq.html">. Otras implementaciones de seguridad de Netscape y un buen punto de partida para estos protocolos se puede encontrar en <htmlurl url="http://home.netscape.com/info/security-doc.html" name="http://home.netscape.com/info/security-doc.html">. <item><bf>S-HTTP:</bf> - S-HTTP es otro protocolo que proporciona servicios de seguridad sobre internet. Fue diseñado para proporcionar servicios seguros a través de internet. Fue diseñado para proporcionar confidencialidad, autenticidad, integridad y no repudiabilidad &lsqb no se puede confundir con nadie] mientras que soporta mecanismos de gestión de múltiples claves y algoritmos de cifrado mediante opción de negociación entre las partes implicadas en cada transacción. S-HTTP está limitado al software específico que implementa y cifra cada mensaje individualmente &lsqb de RSA Cryptography FAQ, página 138] <item><bf>S/MIME:</bf> - S/MIME, o Secure Multipurpose Internet Mail Extension, es un cifrado estándar utilizado para cifrar correo electrónico u otros tipos de mensajes sobre internet. Es un desarrollo estándar abierto de RSA, por tanto existe la esperanza de que con probabilidad lo veremos en Linux pronto. Se puede encontrar más información sobre S/MIME en <htmlurl url="http://home.netscape.com/assist/security/smime/overview.html" name="http://home.netscape.com/assist/security/smime/overview.html">. </itemize>  <sect1> Implementación Linux x-kernel IPSEC Con CIPE, y otras formas de cifrado de datos, hay también una implementación de IPSEC para Linux. IPSEC es un trabajo de IETF para crear comunicaciones cifradas seguras a nivel de red IP, lo que proporciona autenticidad, integridad, control de acceso y cofidencialidad. Se puede encontrar información sobre IPSEC en <htmlurl url="http://www.ietf.org/html.charters/ipsec-charter.html" name="http://www.ietf.org/html.charters/ipsec-charter.html">. También puede encontrar enlaces con otros protocolos que implican gestión de claves y la lista de correo de IPSEC y sus archivos. La implementación de Linux, que estásiendo desarrollada en la Universidad de Arizona, usa una estructura basada en objetos para implementar protocolos de red llamados x-kernel, y se puede encontrar en <htmlurl url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html" name="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html">. De forma más simple, x-kernel es u método de pasar mensajes al nivel del núcleo, que hace una más fácil implementación. Como con las otras formas de cifrado, no se distribuye con el núcleo por defecto, debido a restricciones de exportación.  <sect1> SSH (Secure Shell), stelnet SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y tener una conexión cifrada. SSH es un conjunto de programas usados como sustitución segura de rlogin, rsh y rcp. Usa claves públicas de cifrado para cifrar las comunicaciones entre dos hosts, también como para la verificación de claves. Esto se puede usar para asegurar las conexiones a un host remoto o copiar datos entre hosts, mientras que previene los ataques en el intermedio (secuestro de sesión) y falsificación de DNS (DNS spoofing). Realizará una conexión de los datos de su conexión y asegura las comunicaciones X11 entre hosts. La página principal de SSH, se puede encontrar en <htmlurl url="http://www.cs.hut.fi/ssh/" name="http://www.cs.hut.fi/ssh/"> También puede usar SSH desde su estación de trabajo Windows hacia su servidor SSH Linux. Hay varias implementaciones de clientes Windows de libre disposición, incluyendo el que hay en <htmlurl url="http://guardian.htu.tuwien.ac.at/therapy/ssh/" name="http://guardian.htu.tuwien.ac.at/therapy/ssh/"> y también implementaciones comerciales de DataFellows, en <htmlurl url="http://www.datafellows.com" name="http://www.datafellows.com">. SSLeay es un implementación libre del protocolo Secure Sockets Layer de Netscape, que incluye varias aplicaciones, tales como Secure telnet, un módulo para Apache, varias bases de datos como varios algoritmos incluyendo DES, IDEA y Blowfish. Al usar esta biblioteca, se ha creado un telnet seguro que realiza cifrado sobre las conexiones telnet. A diferencia de SSH, stelnet usa SSL, el protocolo Secure Sockets desarrollado por Netscape. Puede encontrar Secure telnet y Secure FTP empezando con las FAQ SSLeay disponibles en <htmlurl url="http://www.psy.uq.oz.au/~ftp/Crypto/" name="http://www.psy.uq.oz.au/~ftp/Crypto/">  <sect1> PAM - Pluggable Authentication Modules Las nuevas versiones de la distribución Red Hat Linux vienen con un esquema de verificación uinificado llamado "PAM". PAM le permite cambiar sobre la marcha los métodos de verificación, requisitos y encapsular todos los metodos de verificación sin recompilar ninguno de los binarios. La configuración de PAM va más allá de los objetivos de este documento pero asegúrese de echarle un vistazo a la web de PAM para una mayor información <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/index.html" name="http://www.kernel.org/pub/linux/libs/pam/index.html"> Sólo algo de lo que puede hacer con PAM: <itemize> <item> Usa un cifrado no DES para sus claves. (Haciendo más difícil descifrarlas por la fuerza bruta). <item> Pone límite a los recursos sobre todos los usuarios para que no puedan realizar un ataque de denegación de servicios (número de procesos, cantidad de memoria, etc). <item> Activa shadow passwords (ver abajo) sobre la marcha <item> permite a usuarios específicos conectar sólo a horas específicas desde lugares específicos. </itemize> Con unas pocas horas de instalación y configuración de su sistema puede prevenir muchos ataques antes de que ocurran. Por ejemplo, use PAM para desactivar los ficheros rhost del sistema (generales o de punto) en los directorios home de los usuarios añadiendo estas líneas a /etc/pam.d/login: <tscreen><verb> # # Desactivae rsh/rlogin/rexec para usaurios # login auth required pam_rhosts_auth.so no_rhosts </verb></tscreen>  <sect1>Cryptographic IP Encapsulation (CIPE) El primer objetivo de este software es proporcionar facilidades para asegurar (contra escuchas, incluyendo análisis de tráfico e inyección de mensajes falsos) en comunicaciones entre subredes a través de una red de paquetes inseguros como es Internet. CIPE cifra los datos a nivel de red. El viaje de los paquetes entre hosts se hace cifrado. La máquina de cifrado está situada cerca del driver que envía y recibe los paquetes. Esto es, a diferencia de SSH que cifra los datos por conexión, a nivel de socket. Así un conexión lógica entre programas que se ejecutan en hosts diferentes está cifrada. CIPE se puede usar en tunnelling parrr crear una Red Virtual Privada. El cifrado a bajo nivel tiene la vantaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningún cambio en el software de aplicación. Sumario de documentación CIPE : El estándar IPSEC define un conjuntos de protocolos que se pueden usar (entre otras cosas) para construir RVP. Sin embargo, IPSEC es un protocolo más complicado con un montón de opciones implementadas en todo el protocolo que raramente se usan y algunas características (como gestión de claves) que no están completamente resueltas. CIPE usa una simple aproximación, en la cual muchas cosas que se pueden parametrizar (como la elección del algoritmo actual de cifrado usado) se elijen 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 ...). Se puede encontrar más información en <htmlurl url="http://www.inka.de/~bigred/devel/cipe.html" name="http://www.inka.de/~bigred/devel/cipe.html"> Como otras formas de cifrado, esto no se distribuye con el núcleo por defecto debido a restricciones a la exportación.  <sect1> Kerberos Kerberos ees un método de verificación desarrollado por el Athena Project en el MIT. Cuando un usuario se conecta, la Kerberos verifica que es el usuario (usando clave), y proporciona el usario con una forma de probar su identidad a otros servidores y hosts dispersos en la red. Esta verificación se usa por programas como rlogin para permitir al usuario conectarse a otros hosts sin clave (en lugar del fichero rhosts) . La verificación también se usa por el sistema de correo para garantizar que el correo se entrega a la persona correcta, como también garantizar que el remitente es quien dice ser. El efecto global de instalar Kerberos y los numerosos programas que van el él, es eliminar virtualmente la posibilidad de que un usuario haga "spoof" en el sistema, creyendo que es otro. Desafortunadamente, la instalación de Kerberos es muy entrometida, y requiere la modificación o sustitución de numerosos programas estándar. Puede encontrar más información sobre kerberos en <htmlurl url="http://www.veritas.com/common/f/97042301.htm" name="http://www.veritas.com/common/f/97042301.htm"> y el código se puede encontar en <htmlurl url="http://nii.isi.edu/info/kerberos/" name="http://nii.isi.edu/info/kerberos/"> [From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]  <sect1> Shadow Passwords. Shadow passwords es un sistema para mantener sus claves cifradas secretas para los usuarios normales. Normalmente estas claves cifradas se almacenan en su fichero /etc/passwd que tiene lectura pública. Esto facilita que alguien pueda ejecutar programas para averiguar las claves en un intento de determinarlas. Shadow passwords guardan su información en el fichero /etc/shadow que sólo se puede leer con privilegios de superusuario. Para ejecutar shadow passwords tiene que estar seguro de que todas las utilidades que necesitan el acceso a la información de claves están compiladas con para soportar PAM (arriba) también le permite poner un módulo shadow y no requiere la recompilación de ejecutables. Se puede dirigir al Shadow-Password HOWTO para más información si es necesario. Está disponible en <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html" name="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"> Está actualizado ahora y no será necesario para distribuciones que soporten PAM.  <sect1> Crack y John the Ripper Si por alguna razón su programa passwd no fuerza claves fuertes le puede interesar ejecutar un programa para romper claves y estar seguro de que las claves son seguras. Los programas para la rotura de claves funcionan a partir de una idea simple. Intentan todas las palabras del diccionario y después variaciones sobre estas palabras. Cifra cada un de estas palabras y la compara con la clave cifrada. Si coinciden la hemos encontrado. Hay varios programas, los más notables son "Crack" y "John the Ripper" <htmlurl url="http://www.false.com/security/john/index.html" name="http://www.false.com/security/john/index.html"> . Consumen un montón de tiempo de CPU, pero deberían decirle si un atacante podría obtener las claves y después notificárselo a los usuarios con una clave débil. Observe que un atacante primero tendría que usar otro agujero para conseguir las claves cifradas (el fichero unix /etc/passwd), pero esto es más frecuente de lo que podría pensar.  <sect1> CFS - Cryptographic File System y TCFS - transparent cryptographic File System CFS es una forma de cifrar un sistema de ficheros completo y permitir a los usuarios almacenar ficheros cifrados en ellos. Si usa un servidor NFS corriendo en la máquina local, hay rpms disponibles en <htmlurl url="http://www.replay.com/redhat/" name="http://www.replay.com/redhat/"> y más información sobre como funciona en: <htmlurl url="ftp://ftp.research.att.com/dist/mab/" name="ftp://ftp.research.att.com/dist/mab/"> TCFS es una mejora sobre CFS, añadiendo más integración con el sistema de ficheros, de forma que es transparente a cualquier usuario que use el sistema de ficheros que está cifrado. Más información en: <htmlurl url="http://edu-gw.dia.unisa.it/tcfs/" name="http://edu-gw.dia.unisa.it/tcfs/" >  <sect1> X11, SVGA and display security  <sect2> X11 Es importante asegurar su salida gráfica para prevenir que los atacantes hagan cosas como: grabar sus claves mientras las introduce, sin que lo sepan, leer documentos o información que tiene en la pantalla, o incluso usar un agujero para obtener acceso de superusuario. La ejecución remota de aplicaciones X sobre la red también puede ser llenada con peligro, permitiendo que los espías (sniffers) vean toda su interacción con el sistema remoto. X tiene cierto número de mecanismos de control. El más simple es el basado en el host. Puede usar xhost para especificar a qué hosts se les acceder a su display. Esto no es muy seguro de todas formas. Si alguien tiene acceso a su máquina puede hacer xhost + su máquina y entrar fácilmente. También, si tiene que permitir acceso de una máquina insegura cualquiera puede comprometer su display. Cuando use (x display manager) para entrar al sistema, tiene un método mucho mejor de acceso: MIT-MAGIC-COOKIE-1. Se genera un cookie de 128bit y se almacena en su fichero .Xauthorty. Si necesita permitir acceder a su display a una máquina remota, puede usar el el comando xauth y la información de fichero .Xauthority para proporcionar acceso a esa conexión. Vea el mini-howto Remote-X-Apps disponible en <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html">. También puede usar ssh (vea ssh arriba) para permitir conexiones X seguras. Esto tiene la ventaja de ser también transparente al usuario final, y significa que no circulan por la red datos descifrados. Mire la página de manual de Xsecurity para mas información sobre la seguridad en X. La mejor apuesta es usar xdm para conectarse a su consola y entonces ssh para ir a los sitios remotos en los que quiere ejecutar aplicaciones.  <sect2> SVGA Los programas de SVGAlib son típicamente SUID-root para poder acceder a todo su hardware de video de su máquina Linux. Esto los hace muy peligrosos. Si fallan, típicamente necesita reiniciar su máquina para tener una consola utilizable. Esté seguro de que cualquier programa SVGA que ejecuta es auténtico, y que al menos se puede confiar. Incluso mejor, no los ejecute.  <sect2> GGI (Generic Graphics Interface project) El proyecto Linux GGI está intentando resolver varios problemas con los interfaces de de video sobre Linux. GGI moverá una pequeña parte del código de video al núcleo de Linux y entonces controlar el acceso al sistema de video. Esto significa que GGI podrá restaurar su consola en cualquier momento a un estado bueno conociso. También permitirá una clave de atención segura para que pueda estar seguro que no hay ningún caballo de Troya de login ejecutándose en su consola. <htmlurl url="http://synergy.caltech.edu/~ggi/" name="http://synergy.caltech.edu/~ggi/">  <sect> Seguridad del Núcleo Esto es una descripción de las opciones de configuración del núcleo que están relacionadas con la seguridad y una explicación de lo que hace y como usarlo. Como el núcleo controla la red de su equipo, es importante que el núcleo sea muy seguro, y que el mismo núcleo no pueda ser comprometido. Para prevenir algunos de los últimos ataques de red, debe intentar mantener una versión del núcleo actualizada. Puede encontrar los nuevos núcleos en ftp://ftp.kernel.org.  <sect1> Opciones de Compilación del Núcleo <itemize> <item>IP: Drop source routed frames (CONFIG_IP_NOSR) Esta opción debería estar activada. Source routed frames contienen la ruta completa de sus destinos dentro del paquete. Esto significa que los enrutadores a través de los que circula el paquete no necesitan inspeccionarlo, y sólo lo reenvían. Esto podría llevar a que los datos que entran a su sistema puedan ser un exploit potencial. <item>IP: Firewalling (CONFIG_IP_FIREWALL) Esta opción es necesaria si va a configurar su máquina como un cortafuegos, hacer enmascaramiento o desea proteger su estación de trabajo con línea telefónica de qeu alguien entre a través de su interfaz PPP. <item>IP: forwarding/gatewaying (CONFIG_IP_FORWARD) Si activa reenvío IP (IP forwarding), su caja Linux esencialmente se convierte en un encaminador (router). Si su máquina está en una red, podría estar enviando datos de una red a otra, y quizás subvirtiendo un cortafuegos que esté puesto allí para evitar que esto suceda. Los usuario normales de conexión telefónica les interesará desactivar esto y otros usuarios se deberían concentrar en las implicaciones de seguridad de hacer esto. Las máquinas cortafuegos querrán esto activada y usarlo en conjunción con el software de cortafuegos. Puede activarr y desactivar el reenvío IP (IP forwarding) dinámicamente usando el siguiente comando: <tscreen><verb> root# echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> y desactivarlo con el comando: <tscreen><verb> root# echo 0 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> Ese fichero (y muchos otros ficheros de /proc) aparecerán con longitud cero, pero de echo no lo son. Esto es una nueva característica introducida, por lo que tiene que tener un núcleo 2.0.33 o posterior. <item>IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) Esta opción le da información sobre los paquetes que su cortafuegos recibe, como remitente, recipiente, puerto, etc. <item>IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) Generalmente esta opción está desactivada, pero si esta construyendo un host cortafuegos o apra enmascaramiento, deberá activarla. Cuando se envía de un host a otro, no siempre se envía como un simple paquete de datos, sino que se fragmenta en varios trozos. El problema de esto es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que alguien puede insertar información en el resto de los paquetes para su conexión que se supone que no deberían estar allí. <item>IP: syn cookies (CONFIG_SYN_COOKIES) El ataque SYN es un ataque de denegación de servicio (denial of service DoS) que cosume todos los recuroso de su máquina forzando un reinicio. No podemos encontrar ninguna razón por la que no debiera activar esto. <item>Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) Esta es ua opción disponible en los núcleos de la serie 2.1 que firmarán los paquetes NCP para una mayor seguridad. Normalmente puede dejarlo desactivado, pero está allí por si lo necesita. <item>IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) Esta es un hábil opción que le permite analizar los primeros 128 bytes de los paquetes en el espacio de programa de usuario, para determinar si le gustaría aceptar o denegar el paquete basado en su validez. </itemize>  <sect1> Dispositivos del Núcleo Hay algunos dispositivos de bloque y carácter disponibles en Linux que también ayudarán con la seguridad. Los dos dispositivos /dev/random y /dev/urandom los proporciona el núcleo para recuperarar datos aleatorios en cualquier instante. Ambos, /dev/random y /dev/urandom deberían ser suficientemente seguros como para generar claves PGP, SSH y otras aplicaciones donde son un equisito números aleatorios seguros. Los atacantes no podrían ser capaces de determinar el siguiente número dada cualquier secuencia de números con este origen. Se han puesto muchos esfuerzos para asegurar que los números que obtiene de esta fuente son aleatorios en todos los sentidos de la palabra aleatorio. La única diferencia es que /dev/random suministra bytes aleatorios y le hace esperar para que se acumulen más. Observe que en algunos sistemas puede bloquear durante un rato a la espera de que se genere una nueva entrada de usuario al sistema. Por tanto debe tener cuidado al usar /dev/random. (Quizás lo mejor que puede hacer es usarlo cuando esté generando información sensible de claves e indicarle al usuario que pulse una tecla repetidas veces hasta que indique por la pantalla "OK, es suficiente"). /dev/random tiene gran calidad e entropía, midiendo tiempos entre interrupciones etc. Bloquea hasta que hay dispoibles suficientes bits de datos aleatorios. /dev/urandom es parecido, no es tan seguro, pero suficiente para la mayoría de las aplicaciones. Puede leer los dispositivos usando algo parecido a lo siguiente: <tscreen><verb> root# head -c 6 /dev/urandom | uuencode - </verb></tscreen> Esto imprimirá seis caracteres aleatorios en la consola, válidos para la generación de una clave. Vea /usr/src/linux/drivers/char/random.c para obtener una descripción del algoritmo. Gracias a Theodore Y. Ts'o, Jon Lewis, y otros del Linux-kernel por ayudarme (Dave) con esto.  <sect> Seguridad de Red La seguridad en redes se está volviendo más y más importante ya que la gente pasa cada vez más tiempo conectada. Comprometer la seguridad de una red es con frecuencia más fácil que hacerlo con la física o local, y mucho más frecuente. Hay un gran número de herramientas para ayudar con la seguridad de una red y mucha información que viene con las distribuciones de Linux.  <sect1> Espías de paquetes (Packet Sniffers) Una de las formas más frecuentes que tienen los intrusos para obtener acceso a más sistemas de su red es usar un espía de paquetes (sniffer) en un host que ya ha sido comprometido. Este "sniffer" escucha en los puertos Ethernet cosas como "Password", "Login" y "su" en el flujo de paquetes y registra el tráfico posterior. De esta forma los atacantes obtienen claves de sistemas que ni siquiera tratan de atacar. Las claves enviadas sin cifrar son muy vulnerables a estos ataques. EJEMPLO: El host A ha sido comprometido. Los atacantes instalan un sniffer. El sniffer recoge los logind del administrador en el host B desde el host C. Consigue las claves personales de los administradores mientras entran en B, entonces el administrador hace un su para corregir un problema. Ahora tienen la clave del root del host B. Más tarde el administrador deja a alguien hacer telnet desde su cuenta al host Z en otro sistio. Ahora el atacante tiene el par password/login en el host Z. En este momento el atacante no necesita ni comprometer el sistema para hacer esto, también podría traer un portátil o un pc al edificio y meterse en su red. El uso de ssh u otros métodos de claves cifradas impide este ataque. Cosas como APOP para cuentas pop también previene este ataque. (Los login pop normales son muy vulnerables en esto, como cualquier cosa que se envía en texto sin cifrar sobre la red).  <sect1> Servicios del sistema y tcp_wrappers Tan pronto como ponga su sistema en cualquier red, lo primero que tiene que mirar es qué servicios necesita ofrecer. Los servicios que no necesita ofrecer los debe desactivar para tener menos cosas de las que preocuparse por un ataque y tener un sitio menos para situar un agujero. Hay varias formas de desactivar servicios bajo Linux. Puede mirar en su fichero /etc/inetd.conf y ver qué servicios están siendo ofrecidos por su inetd. Desactivando los que no necesite comentándolos (# al principio de la línea), y después enviar a su proceso inetd una SIGHUP. También puede eliminar (o comentar) servicios en su fichero /etc/services. Esto significa que los clientes locales tampoco podrán encontrar el servicio si elimina ftp e intenta hacer un ftp a un sitio remoto de su máquina, fallará con un mensaje de servicio desconocido). Es normal no preocuparse de eliminar servicios ya que esto no proporciona ninguna seguridad adicional. Si una persona local quiere usar ftp, incluso aunque haya comentado, el haría su propio cliente que usa el puerto ftp común y funcionaría bien. Algunos servicios que querrá dejar activos son: <itemize><item>ftp <item>telnet <item>mail, como pop-3 o imap <item>identd <item>time </itemize> Si sabe que no va a utilizar algún paquete en particular, puede borrarlo entero, con rpm -e con la distribución Red Hat borrará el paquete entero. Bajo debian dpkg probablemente hace lo mismo. Además, quiere desactivar la utilidades rsh/rlogin/rcp, incluyendo login (usado por rlogin), shell (usado por rcp), y exec (usado por rsh) para que no sean iniciados en /etc/inetd.conf. Estos protocolos son extremadamente inseguros ya han sido causa de exploits en el pasado. Debería comprobar sus /etc/rc.d/rcN.d, donde N es su nivel de ejecución del sistema (systems run level) y ver si alguno de los servidores iniciados en esos directorios no son necesarios. Los ficheros de /etc/rc.d/rcN.d actualmente son enlaces simbólicos al directorio /etc/rc.d/init.d. Renombrar el fichero en el directorio init.d tiene el efecto de desactivar todos los enlaces simbólícos que hay en /etc/rc.d/rcN.d. Si sólo desea desactivar un servicio para un determinado nivel de ejecución, renombre el fichero adecuado con una 's' minúscula en lugar de la 'S' mayúscula como la de S45dhcpd. Si tiene los ficheros rc con el estilo BSD, tendrá que verificar /etc/rc* para los programas que no necesita. La mayoría de las distribuciones Linux vienen con tcp_wrappers que "cubren" todos sus servicios tcp. Un tcp_wrapper (tcpd) se llama desde inetd en lugar del servidor real. Tcpd comprueba entonces el host que solicita el servicio y bien ejecuta el servidor real o deniega el acceso de ese host. Tcpd permite restringir el acceso a sus servicios tcp. Debería crear un fichero /etc/hosts.allow y añadirle sólo aquellos host que necesitan tener acceso a los servicios de su máquina. Si es un usuario de línea telefónica en casa, le sugerimos que deniegue todo (ALL). tcpd también registra los intentos fallidos de acceder a un servicio, y así se puede hacer una idea de que está siendo atacado. Si añade nuevos servicios, debería estar seguro de configurarlos para usar tcp_wrappers. Por ejemplo, un usuario normal de conexión telefónica puede prevenirse de la conexiona a su máquina del exterior, y tener la posibilidad de recuperar correo y efectuar conexiones de red a internet. Para hacer esto podría añadir lo siguiente a su /etc/hosts.allow: ALL: 127. Y desde luego /etc/hosts.deny contendría: ALL: ALL lo que previene de conexiones externas a su máquina, y todavía le permite conectar a servidores de internet desde el interior.  <sect1> Verificar su Información DNS Mantener actualizada la información DNS sobre todos los hosts de su red le puede ayudar a aumentar la seguridad. En el caso de un host no autorizado se conecte a su red, puede reconocerlo por la ausencia de la entrada DNS. Muchos servicios se pueden configurar para no aceptar conexiones de hosts que carecen de entradas DNS válidas.  <sect1> identd identd es un pequño programa que se ejecuta desde su inetd. Mantiene la pista de qué usuario está ejecutando un determinado servicio tcp, e informa de ello cuando se le solicita. Mucha gente confunde la utilidad de identd, y en consecuencia lo desactiva o bloquea todos los sitios que lo solicitan. Identd no está ahí para ayudar a sitios remotos. No hay forma de conocer si los datos que que obtiene del identd remoto son correctos o no. No hay verificación de identidad en las solicitudes de identd. Enonces ¿por qué querría ejecutarlo? Porque le ayuda y es otra fuente de información. Si su identd no está alterado, entonces sabe que le está diciendo el usuario o uid de la gente de los sitios remotos que están usando los servicios tcp. Si el administrador de un sitio remoto viene y le dice que un usuario está intentando entrar (hack) en su sitio, entonces puede fácilmente tomar acciones contra ese usuario. Si no está ejecutando identd, tendrá que mirar un montón de registros para encontrar quien fue a determinada hora, y en general lleva mucho más tiempo encontrar la pista del usuario. El identd que viene con la mayoría de las distribuciones es más configurable de lo que mucha gente cree. Puede desactivar identd para determinados usuarios (pueden crear un fichero .identd), puede registrar todas las peticiones de identd (lo recomiendo) puede incluso tener a identd devolviendo un uid en lugar del nombre de usuario o incluso NO-USER.  <sect1> SATAN , ISS y otros Exploradores de Red Hay varios paquetes diferentes de software que efectúan una exploración basada en puertos y servicios de máquinas o de redes. SATAN y ISS son dos de los mejores conocidos. Este software se conecta con la máquina destino ( o todas las máquinas de la red) en todos su puertos que puede e intenta determinar qué servicio se está ejecutando allí. Basándose en esta información, podría descubrir si la máquina es vulnerable a un exploit específico en ese servidor. SATAN (Security Administrators Tool for Analyzing Networks) es un explorador de puertos con un interfaz web. Se puede configurar para efectuar verificaciones ligeras, medias o fuertes sobre una máquina o red, y fija los problemas que encuentra. Esté seguro de obtener una copia de SATAN de sunsite o un FTP o web con reputación. Había un copia Troyano de SATAN que se distribuía por la red. <htmlurl url="http://www.trouble.org/~zen/satan/satan.html" name="http://www.trouble.org/~zen/satan/satan.html"> ISS (Internet Security Scanner) hay otro explorador basado en puertos . Es más rápido que Satan y en consecuencia podría ser mejor para grandes redes. Sin embargo, SATAN tiende a proporcionar más información. Abacus-Sentry es un explorador de puertos comercial de www.psionic.com. Mire su página home en la web para más información. <htmlurl url="http://www.psionic.com" name="http://www.psionic.com"> Detecting Port scans. Hay algunas herramientas diseñadas para alertarle de pruebas con Satan, ISS y otro software de exploración. De todas formas el uso de tcp_wrappers y estando seguro de buscar en los ficheros regulares de registro debería notar tales pruebas. Incluso en el más bajo nivel, Satan aun deja trazas en los registros en un sistema Red Hat.  <sect1> Sendmail, qmail y MTA's. Uno de los servicios más importantes que puede proporcionar es el servidor de correo. Por desgracia, también es uno de los servicios más vulnerable a los ataques, simplemente debido al número de tareas que debe realizar y los privilegios que típicamente necesita. Si usa sendmail es muy importante mantener la versión actualizada Sendmail tiene una larga, larga historia de fallos de seguridad. Siempre esté seguro de usar la versión más reciente. <htmlurl url="http://www.sendmail.org/" name="http://www.sendmail.org"> Si está cansado de actualizaciones de su versión de sendmail cada semana debería plantearse cambiar a qmail. Qmail se diseñó teniendo en mente la seguridad desde principio a fin. Es más rápido, estable y seguro. <htmlurl url="http://www.qmail.org" name="http://www.qmail.org">  <sect1> Denegación de Servicios Un ataque de denegación de serviciso es uno en que el atacante intenta hacer que algún recurso esté demasiado ocupado para responder solicitudes legítimas o para denegar a los usuarios legítimos acceso a su máquina. Los ataques de denegación de servicios se han incrementado recientemente en los últimos años. Algunos de los más populares y recientes están listados abajo. Observe que aparecen nuevos continuamente, por tanto esto son sólo algunos ejemplos. Lea la lista de seguridad Linux y la lista bugtraq y archivos para una información más actualizada. <itemize><item> <bf>SYN Flooding</bf> - SYN flooding es un ataque de denegación de servicio de red. Se aprovecha de un agujero ("loophole") en la forma en que se crean las conexiones TCP. Los nuevos núcleos de Linux (2.0.30 y posteriores) tienen varias opciones configurables para prevenir ataques SYN flood que denieguen a la gente acceder a su máquina o servicios. Vea la sección de seguridad del núcleo para ver las opciones limpias de rotección del núcleo. <item><bf>Pentium "F00F" Bug</bf> - Recientemente se descubrió que una serie de código ensamblador enviado a un Pentium genuino reiniciabala máquina. Esto afecta a todas las máquinas con un procesador Pentium (no clones, no Pentium Pro o PII), no importa qué operación de sistema esté realizando. Los núcleos Linux 2.0.32 y superiores tienen un trabajo sobre este bug, previniendo que bloquee la máquina. El núcleo 2.0.33 tiene una versión mejorada de la corrección, sugerida sobre 2.0.32. Si está ejecutando un Pentium debería actualizarse ahora. <item> <bf>Ping Flooding</bf> - Ping flooding es un simple ataque de denegación de servicio por la fuerza bruta. El atacante envía una "inundación" (flood) de paquetes ICMP a su máquina. Si están haciendo esto desde un host con mayor ancho de banda que su máquina, será incapaz de enviar nada a la red. Una variante de esta ataque llamado "smurfing", envía paquetes ICMP a un host con la dirección IP de retorno de su máquina, permitiéndoles que la inundación sea menos detectable. Puede encontrar más información sobre ataques "smurf" en <htmlurl url="http://www.quadrunner.com/~chuegen/smurf.txt" name=" http://www.quadrunner.com/~chuegen/smurf.txt"> Si en alguna ocasión está bajo un ataque ping flood, use una herramienta como tcpdump para determinar de donde vienen los paquetes (o parece que vienen), entonces contacte con su proveedor con esta información. Los ping floods se pueden parar con más facilidad a nivel de encaminador o usando un cortafuegos. <item> <bf>Ping o' Death</bf> - El ataque Ping o' Death es el resultado de paquetes entrantes ICMP ECHO REQUEST que son más grandes que lo que pueden almacenar las estructuras de datos del núcleo que recogen esta información. Como enviar un simple paquete ping grande (65,510 bytes) "ping" a muchos sistemas, los cuelga o los rompe, este problema fue rápidamente resuelto. Este ha sido resuelto y ya no hay nada de qué preocuparse. <item> <bf>Teardrop / New Tear</bf> - Uno de los más recientes exploits que usan un bug presente en el código de fragmentación IP en plataformas Linux y Windows. Se corrigió en la versión del núcleo 2.0.33, y no requiere seleccionar ninguna opción de compilación del núcleo para usar la corrección. Linux aparentemente no es vulnerable al exploit 'newtear'. </itemize> Puede encontrar más código de exploits y más descripciones en profundidad de como funcionan en <htmlurl url="http://www.rootshell.com" name="http://www.rootshell.com"> usando su motor de búsqeda.  <sect1> Seguridad NFS (Network File System) NFS es un protocolo para compartir ficheros ampliamente utilizado. Permite a los servidores ejecutar nfsd y mountd para "exportar" sistemas de ficheros completos a otras máquinas con soporte de sistemas de ficheros nfs incorporado en el núcleo (u otro cliente que lo soporte si no son máquinas Linux). Mountd mantiene una pista de los sistemas de ficheros montados en /etc/mtab, y puede mostrarlos con 'showmount'. Muchos stios usan NFS para servir directorios home a sus usuarios, de forma que sin importar en qué máquina del grupo se conectan, tienen su directorio home y ficheros. Hay alguna parte de "seguridad " permitida al exportar sistemas de ficheros. Puede hacer que su nfsd mapee al usuario root remoto (uid=0) al usuario nobody, denegándole acceso total a los ficheros exportados. Sin embargo, como los usuario individuales tienen acceso sus propios ficheros (o al menos con el mismo uid), el superusuario remoto puede entrar en su cuenta y tener acceso total a sus ficheros. Esto es sólo un pequeño inconveniente para un atacante que tiene acceso para montar su sistema de ficheros remoto. Si tiene que usar NFS, esté seguro de que exporta sólo a aquellas máquinas que realmente necesita exportar. Nunca exporte su directorio raíz completo, exporte sólo los directorios que necesita exportar. Vea el NFS HOWTO para más información sobre NFS: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NFS-HOWTO.html" name="NFS HOWTO">  <sect1> NIS (Network Information Service) (conocido como YP). Network Information service (llamado YP) es un medio de distribuir información a un grupo de máquinas. El NIS principal recoge las tablas de información y las convierte en ficheros de mapas NIS. Estos mapas son servidos sobre la red, permitiendo a las máquinas NIS clientes conseguir login, claves, directorio home e información de shell (toda la información estándar del fichero /etc/passwd file). Esto permite a los usuarios cambiar sus claves una vez y que tenga efecto en todas las máquinas del dominio NIS. NIS no es del todo seguro. No nació para esto. Nació para ser útil y manejable. Cualquiera que puede averiguar el nombre de su dominio NIS (cualquiera de la red) puede obtener una copia del fichero passwd, y usar crack o john the ripper con las claves de usuarios. También es posible falsificar NIS y hacer toda clase de trucos sucios. Si tiene que uar NIS, esté seguro de que está prevenido de los peligros. Hay una sustitución de NIS mucho mas segura, llamada NIS+. Mire el NIS HOWTO para más información: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html">  <sect1> Cortafuegos (Firewalls) Los cortafuegos son medios de restringir qué información se permite que entre y salga de su red local. Normalmente el host cortafuegos está conectado a Internet y a su red local, y sólo se accede desde su red a internet a través del cortafuegos. Esta forma de cortafuegos puede controlar qué pasa y sale de internet y su red local. Hay diversas formas y métodos de activar un cortafuegos. La máquinas Linux pueden hacer cortafuegos a muy bajo coste. El código de los cortafuegos se puede construir con núcleos 2.0 y superiores. Las herramientas ipfwadm le permiten cambiar los tipos de tráfico de red que permite sobre la marcha. También puede registrar tipos de trafico particulares de la red. Los cortafuegos son muy útiles y es un técnica importante para asegurar su red. Es imoprtante darse cuenta que nunca debería pensar que como tiene un cortafuegos no necesita asegurar las máquinas que están detrás de él. Esto es un error fatal. Mire el Firewall-HOWTO en su último fichero en <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"> para más información sobre cortafuegos y Linux. More information can also be found in the IP-Masquerade mini-howto: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html" name="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"> Más información sobre ipfwadm (La herramienta que le permite cambiar el estado de su cortafuegos, la puede encontrar en su página home en: <htmlurl url="http://www.xos.nl/linux/ipfwadm/" name="http://www.xos.nl/linux/ipfwadm/">  <sect> Preparación para la Seguridad (antes de conectarse) Ha comprobado su sistema y ha determinado que es tan seguro como necesita y que está listo para conectarse. Hay unas cuantas cosas que debería hacer para prepararse en caso de una intrusión que actualmente suceden, de forma que rápidamente desactive al intruso y volver a funcionar.  <sect1> Hacer una Copia de Salvaguardia de su Máquina Las discusiones de los métodos de copias de salvaguardia está fuera de los objetivos de este documento, sólo unas pequeñas palabras relacionadas con copias de salvaguardia y seguridad. Si tiene menos de 650Mb de datos almacenados en una partición, una copia CD-R de sus datos es una buena forma de hacerlo (ya que es más difícil de falsificar con posterioridad, y si están almacenados de forma adecuada pueden durar mucho tiempo). Las cintas y otros medios sobre los que se puede escribir deberían protegerse tan pronto como se completa la copia y se verifica para evitar la falsificación. Tenga cuidado y almacene su copia de seguridad en un sitio seguro. Una buena copia de seguridad le asegura que tiene un buen punto desde el que restaurar su sistema.  <sect1> Escoger una Buena Secuencia de Copias Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta pra cada Viernes y una cinta para para los Viernes impares. Realice una copia incremental cada día, y una copia completa en la cinta adecuada de cada Viernes. Si hace algún cambio importante o añade datos importantes a su sistema también seríaadecuado efectuar una copia.  <sect1> Copiar su Base de Datos RPM o Debian En el caso de que un intruso entre en su sistema, puede usar su base de datos RPM como trampa, pero sólo si está seguro de que no ha sido modificada. Debería copiar la base de datos RPM en un disquete y mantenerla alejada siempre. La distribución Debian probablemente tiene algo similar. Especialmente los ficheros /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm probablemente no cabrán en un sólo disco. Ahora cuando su sistema haya sido comprometido puede usar el comando: <tscreen><verb> root# rpm -Va </verb></tscreen> para verificar cara fichero del sistema. Vea la página de manual de RPM, ya que allí hay algunas otras opciones que se pueden incluir para dar más información. Esto significa que cada vez que se añade un nuevo RPM al sistema, la base de datos RPM tendrá que ser rearchivada. Tendrá que decidir entre ventajas e inconvenientes.  <sect1>Mantener la Pista de Sus Datos de Contabilidad del Sistema Es muy importante que la información que llega con syslog no haya sido comprometida. Hacer que los ficheros de /var/log tengan lectura y escritura por un número limitado de usuarios es un buen comienzo. Esté seguro de tener un ojo en lo que se escribe allí, especialmente con la utilidad 'auth'. Muchos fallos de login, por ejemplo, pueden indicar un intento de romper la seguridad del sistema. Lo que debe buscar en los registros dependerá de la distribución. En sistemas Linux que verifican el Estándar de Sistema de Ficheros Linux ( "Linux Filesystem Standard"), como Red Hat, tendrá que mirar en /var/log and y comprobar messages, mail.log, y otros. Puede encontrar donde su distribución registra la información mirando en su /etc/syslog.conf file. Este es el fichero que le dice a syslogd (el demonio de registros del sistema) donde registrar los distintos mensajes. Podría también querer configurar el guión (script) de rotación de sus logs para una mayor duración para que le dé tiempo a examinarlos. Dele un vistazo a paquete logrotate de las distribuciones recientes de Red Hat. Otras distribuciones probablemente tengan un proceso similar. Si su ficheros de registro han sido falsificados, determine cuando se inició y qué tipo de cosas parece que se han falsificado. ¿Hay largos periodos en los que no aparecen registros? Comprobar las cintas de copias de salvaguardia (si las tiene) para ver ficheros no falsificados puede ser una buena idea. Los ficheros de de registro normalmente se modifican por el intruso para cubrir sus pistas, pero se deberían comprobar para buscar sucesos extraños. Puede darse cuenta del intruso que está intentando obtener acceso o explotar un programa para conseguir acceso de root. Debe ver los registros antes de que el intruso tenga tiempo de modificarlos. Debería también estar seguro de separar la facilidad 'auth' de otros datos de registros, incluyendo intentos de cambios de usuario usando 'su', intentos de conexión y otra información de contabilidad. Si es posible, configure syslog para enviar una copia de los datos más importantes a un sistema seguro. Esto nos prevendrá de que un intruso cubra sus huellas borrando sus intentos login/su/ftp/etc. Vea la página de manual de syslog.conf y busque la opción `@'. Finalmente los ficheros de registro son mucho menos útiles cuando nadie los lee. Tome algún tiempo de vez en cuando para mirar sus registros, y vea como son en un día normal. Esto, le será útil para distinguir cuando pasa algo inusual.  <sect1> Aplicar Todas las Nuevas Actualizaciones del Sistema La mayoría de los usuarios de Linux instalan desde un CDROM. Debido a la rapidez con que corrigen los problemas de seguridad, siempre están apareciendo nuevas versiones de los programas. Antes de que conecte su máquina a la red es una buena idea verificar con el sitio ftp se su distribución (ftp.redhat.com por ejemplo) y conseguir todas los paquetes de actualizaciones desde que salió su CDROM de distribución. Muchas veces estos paquetes contienen importantes correcciones de seguridad, por lo que es conveniente tenerlos instalados.  <sect> ¿Qué hacer Durante y Después de una Ruptura? ¿Ha seguido algunos de las advertencias que se indicaban aquí (o en otro sitio) y ha detectado una ruptura? Lo primero es mantener la calma. Las acciones apresuradas pueden causar más daño que el que podría causar un atacante.  <sect1> Compromiso de seguridad en Curso. Localizado un compromiso de seguridad en curso puede ser una tarea tensa. Según reaccione puede tener graves consecuencias. Si el compromiso que está viendo es físico, ha pillado a alguien que ha entrado en su oficina o laboratorio, tendría que notificarlo a las autoridades. En un laboratorio puede estar intentado abrir la caja o reiniciar una máquina. Dependiendo de su autoridad y procedimientos, le podría decir que parara o llamar a un servicio de seguridad. Si ha detectado a un usuario local intentando comprometer la seguridad lo primero que tiene que hacer es confirmar que realmente es quien parece ser. Compruebe el sitio si tiene registros de login. ¿Está en el sitio habitual? Entonces use un medio no electrónico para ponerse en contacto. Por ejemplo, llámelo por teléfono o vaya andando por el edificio/casa y hable con ellos/ellas. Si reconocen que están conectados, puede preguntarles la explicación qué están haciendo o decirles que dejen de hacerlo. Si no están conectados y no tienen ni idea de lo que les está hablando, este incidente requiere una mayor investigación. Busque en el incidente, y consiga un montón de información antes de hacer acusaciones. Si ha detectado un compromiso de red, lo primero que tiene que hacer (si puede) es desconectar la red. Si están conectados mediante módem, desconecte el cable del módem. Si están conectados vía ethernet, desconecte el cable de ethernet. Esto prevendrá que hagan más daño, y ellos además lo verán más como un problema de red más que una detección. Si no puede desconectar la red (si tiene un sitio ocupado, o no tiene control físico de la máquina), el mejor paso siguiente es usar algo como tcp_wrappers o ipfwadm para denegar accesos del sitio de donde se hace la intrusión. Si no puede denegar a toda la gente del mismo sitio del intruso, cierre la cuenta del usuario. Observe que cerrar una cuenta no es una cosa simple. Tiene que tener en cuenta los ficheros .rhosts, el acceso FTP y otras puertas traseras. Tras haber hecho lo anterior (desconectar la red, denegar el acceso de sitio y/o desactiva la cuenta), necesita matar todos sus procesos de usuario y desconectarlos. Debería monitorizar su sitio bien durante los próximos minutos, ya queel atacante intentará regresar. Quizás usando un cuenta diferente y/o de diferente dirección de red.  <sect1> El Compromiso de Seguridad ya ha Ocurrido Bueno, bien ha detectado un compromiso que ya a ocurrido o bien lo ha detectado y ha echado (espero) al atacante fuera de su sistema. ¿Y ahora qué?  <sect2> Cerrar el Agujero Si ppuede determinar qué medios usó el atacante para entrar en su sistema, debería intentar cerrar el agujero. Por ejemplo, quizás ha visto varias entradas FTP justo antes de que el usuario entrara. Desactive el servicio FTP y compruebe y vea si hay una versión actualizada o alguna de la lista conocida de correcciones. Verifique todos su ficheros de registro y haga una visita a sus páginas de listas de seguridad y vea allí su hay algún nuevo exploit común que pueda corregir. Puede encontrar las correcciones de seguridad de Caldera aquí <htmlurl url="http://www.caldera.com/tech-ref/security/" name="http://www.caldera.com/tech-ref/security/">. Red Hat no tiene separados sus correcciones de seguridad de errores, pero las erratas de sus distribuciones están disponibles en <htmlurl url="http://www.redhat.com/errata" name="http://www.redhat.com/errata"> Es muy probable que alguno delos vendedores haya editado una actualización de seguridad, que la mayoría de los otros Linux también harán. Si no elimina el atacante, probablemente volverá. No a su máquina, sino a cualquiera otra de la red. Si ejecutaban algún sniffer, tiene buenos recursos para tener acceso a las máquinas locales.  <sect2> Valoración del Daño Lo siguiente que tiene que hacer es evaluar el daño. ¿Qué se ha comprometido? Si ejecuta un Verificador de Integridad como Tripwire podría decírselo. Si no, tendrá que mirar todos sus datos importantes. Como los sistemas Linux se están volviendo más y más fáciles de instalar, podría considerar guardar sus ficheros de configuración y limpiar los discos y reinstalar, y después restaurar sus ficheros de usuario de las copias de seguridad y los ficheros de configuración. Esto asegura que tiene un sistema limpio. Si tiene ficheros de copias de seguridad del sistema comprometido, sea especialmente cuidadoso con los binarios que restaura, ya que pueden ser caballos de troya situados allí por el intruso.  <sect2> Backups, Backups, Backups! Tener copias regulares de seguridad es una suerte para asuntos de seguridad. Si su sistema está comprometido, puede restaurar los datos que necesite de estas copias. Desde luego, algunos datos tienen valor para los atacantes y no sólo los destruirán , los robarán y tendrán sus propias copias, pero al menos tiene los datos. Debería verificar varias copias de salvaguardia anteriores antes de restaurar un fichero que haya sido falsificado. El intruso podría haber comprometido sus ficheros hace tiempo y podría haber hecho muchas copias de seguridad del fichero falsificado. Desde luego, también tiene que tener seguras sus copias de salvaguardia. Tenga cuidado de guardarlas en lugar seguro. Saber quien tiene acceso a ellos. (Si un atacante puede obtener las copias de seguridad, puede obtener acceso a todos los datos sin que ni siquiera lo sepa).  <sect2> Siguiendo la Pista del Intruso. Ha expulsado al intruso y ha recuperado su sistema, pero no todo está hecho. Mientras sea improbable que la mayoría de los intrusos sean capturados, debería informar del ataque. Debería informar del ataque al contacto con el admin en el sitio de donde el atacante atacó a su sistema. Puede buscar este contacto con whois o la base de datos del internic. Podría enviarles un mensaje de correo con todos los registros aplicables y fechas y horas. Si tiene algo más distintivo sobre su intruso, podría mencionarlo también. Tras enviar el correo (si le parece bien) podría llamar por teléfono. Si el admin localiza a su atacante, podría hablar con él. Los buenos hackers con frecuencia usan muchos sistemas intermedios. Algunos (o muchos) puede que ni sepan que han sido comprometidos. Intentar seguir la pista de un cracker hasta su origen puede ser difícil. Siendo educado con los admins le puede llevar un largo recorrido obtener ayuda de ellos. Debería notificarlo también a alguna organización de seguridad de la que foram parte (CERT o similar).  <sect> Security Sources Hay un montón de buenos sitios para seguridad de Unix en general y seguridad de Linux en particular. Es muy importante suscribirse a una o más listas de correo de seguridad y estar actualizado sobre las correcciones de seguridad. La mayoría de las listas tienen muy bajo volumen y son muy informativas.  <sect1> Sitios FTP CERT es el Computer Emergency Response Team. Con frecuencia envían alertas sobre ataques actuales y correciones. <htmlurl url="ftp://ftp.cert.org" name="cert.org"> Replay tiene archivos de muchos programs de seguridad. Como están fuera de EE.UU. no están sujetos a la obediencia a las restricciones de cifrado <htmlurl url="ftp://ftp.replay.com" name="replay.com"> Matt Blaze es el autor de CFS y un gran defensor de la seguridad. <htmlurl url="ftp://ftp.research.att.com/pub/mab" name="Matt Blaze's stuff"> tue.nl es un gran sitio ftp de seguridad en Holanda. <htmlurl url="ftp://ftp.win.tue.nl/pub/security/" name="ftp.win.tue.nl">  <sect1> Sitios Web The Hacker FAQ es una FAQ sobre hackers: <htmlurl url="http://www.solon.com/~seebs/faqs/hacker.html" name="The Hacker FAQ"> En castellano http://usuarios.santafe.com.ar/~cballard/pf/hacker-howto.es.html El archivo COAST tiene un gran número de programas de seguridad Unix e información: <htmlurl url="http://www.cs.purdue.edu/coast/" name="COAST"> Rootshell.com es un gran sitio para ver qué exploits están siendo utilizados actualmente por los crackers: <htmlurl url="http://www.rootshell.com/" name="rootshell.com exploits"> BUGTRAQ pone avisos de temas de seguridad: <htmlurl url="http://www.netspace.org/lsv-archive/bugtraq.html" name="BUGTRAQ archives"> CERT, el Computer Emergency Response Team, pone avisos sobre ataques comunes a plataformas Unix: <htmlurl url="http://www.cert.org/" name="CERT home"> Dan Farmer es el autor de SATAN y otras muchas herramientas, su sitio tiene información interesante junto con herramientas de seguridad: <htmlurl url="http://www.trouble.org" name="Dan Farmers trouble.org"> La Linux security WWW es un buen sitio para consguir información de seguridad para Linux: <htmlurl url="http://www.aoy.com/Linux/Security/" name="Linux Security WWW"> Reptile tiene montones de buena información sobre seguridad en Linux en su sitio: <htmlurl url="http://207.237.120.45/linux/" name="Reptiles Linux Security Page"> Infilsec tiene un motor de vulnerabilidad que puede decirle que vulnerabilidades afectan a una plataforma específica: <htmlurl url="http://www.infilsec.com/vulnerabilities/" name="Infilsec vunerability engine"> CIAC envía construcciones periódicas de seguridad sobre exploits comunes: <htmlurl url="http://ciac.llnl.gov/cgi-bin/index/bulletins" name="CIAC bulitins"> Un buen buen punto de inicio para Linux Pluggable Authentication Mdules (PAM) se puede encontar en <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/" name="http://www.kernel.org/pub/linux/libs/pam/">.  <sect1> Listas de correo Bugtraq: Para suscribirse a bugtraq, envíe un mail a listserv@netspace.org que contenga en el cuerpo del mensaje subscribe bugtraq. (ver el enlace anterior para los archivos). CIAC: Envíe un e-mail a: majordomo@tholia.llnl.gov En el cuerpo(no en el subject) del mensaje ponga: subscribe ciac-bulletin  <sect1> Libros - Material Impreso Listo Hay muy buenos libros de seguridad. Esta sección lista unos pocos de ellos. Además, los libros específicos de seguridad, la seguridad está cubierta en gran número de libros sobre administración. Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4  <sect> Glosario <itemize> <item><bf>Host:</bf> Un sistema (ordenador, computador) agregado a una red. <item><bf>Cortafuegos (Firewall):</bf> Un componente o conjunto de componentes que restringe el acceso entre un red protegida e internet u otro conjunto de redes. <item><bf>Host Bastiont:</bf> Un host que tiene que ser altamente seguro porque es vulnerable a ataques, normalmente porque está expuesto a internet y es un punto de contacto principal de usuarios de redes internas. Obtiene su nombre de los proyectos altamente fortificados de los muros exteriores de los castillos medievales. Los bastiones vigilan áreas críticas de defensa, normalmente con fuertes muros, habitáculos para tropas extras, y los tubos ocasionales de aceite hirviente para disuadir a los atacantes. <item><bf>Host Dual-homed:</bf> Un host de propósito general que tiene al menos dos interfaces de red. <item><bf>Paquete (Packet):</bf> La unidad fundamental de comunicación en internet. <item><bf>Filtrado de Paquetes (Packet Filtering):</bf> La acción que toma un dispositivo para controlar selectivamente el flujo de datos desde y hacia la red. Los filtros de paquetes permiten o bloquean paquetes, normalmente mientras los enruta de una red a otra (con más frecuencia de internet a un red interna y viceversa). Para llevar a cabo el filtrado de paquetes tiene que activar un conjunto de reglas que especifican qué tipo de paquetes (los que vienen a van a una determinada dirección IP o puerto) se permiten que tipos se bloquean. <item><bf>Red de Perímetro (Perimeter network):</bf> Una red añadida entre una red protegida y la red externa, para proporcionar una seguridad añadida. A una red de perímetro también se la denomina a veces una DMZ. <item><bf>Servidor Proxy (Proxy server):</bf> Un programa que trata con servidores externos en nombre de los clientes internos. Los clientes proxy hablan con el servidor proxy, que rehace las peticiones de los clientes hacia un servidor real y devuelve sus respuestas a los clientes. <item><bf>Denegación de Servicio (Denial of Service):</bf> Un ataque de denegación de servicio es cuando un atacante consume los recursos de un equipo por cosas que no estaba intentando hacer, así impidiendo el uso normal de los recursos de su red para propósitos legítimos. <item><bf>Desbordamiento del Buffer (Buffer Overflow) :</bf> El estilo de codificación común nunca asigna buffer suficientemente grandes y no comprueba los desbordamientos. Cuando esos buffer se desbordan, el programa en ejecución (demonio o programa set-uid) se puede trucar para hacer algunas cosas. Generalmente esto funciona sobreescribiendo la dirección de retorno de una función en la pila para apuntar a otra ubicación. <item><bf>Falsificación IP (IP Spoofing):</bf> IP-Spoofing es una técnica compleja de ataque que se hace de varios componentes. Es un exploit de seguridad que funciona engañando a equipos con una relación de confianza por alguien que no es quien dice ser. Hay un trabajo extenso escrito por daemon9, route e infinity en el Volume Seven, Issue Fourty-Eight de Phrack Magazine. <item><bf>Autenticidad (Authentication):</bf> La propiedad de saber que el dato recibido es el mismo que el dato que fue enviado y que el remitente que dice es el remitente de hecho. <item><bf>No repudiación (Non-repudiation):</bf> La propiedad del receptor de ser capaz de probar que el remitente de algún dato hizo de hecho el envío del dato incluso aunque el remitente pueda más tarde querer denegar haber enviado ese dato. </itemize>  <sect>Preguntas de Uso Frecuente (PUF) Frequently Asked Questions (FAQ) <enum> <item> ¿Es más seguro compilar el soporte del controlador directamente en el núcleo en lugar de crear un módulo? Respuesta: Algunos piensan que es mejor desactivar la posibilidad de cargar controladores de dispositivos usando módulos, porque un intruso podría cargar un módulo troyano o él mismo cargar un módulo que podría afectar a la seguridad del sistema. Sin embargo, para cargar módulos hay que ser root. Los ficheros de objetos módulos sólo tienen escritura por el root. Esto significa que el intruso necesitaría tener acceso de root para insertar un módulo. Si el intruso obtiene acceso de root, hay cosas más serias de las que preocuparse que si ha cargado un módulo. Los módulos son soporte para carga dinámica para un dispositivo particular que no se usa con frecuencia. En máquinas servidoras, o cortafuegos por ejemplo, esto nos es probable que suceda. Por esta razón, tendría más sentido compilar el soporte directamente en el núcleo para máquinas que actúan como servidores. Los módulos también son más lentos que el soporte compilado directamente en el núcleo. <item> Los Login como root desde una máquina remota siempre fallan. Respuesta: Vea la sección sobre seguridad de root. Esto está hecho intencionalmente para prevenir que usuarios remotos intenten conectar mediante telnet a su máquina como root, que sería una seria vulnerabilidad. No olvide, los intrusos potenciales tienen el tiempo de su parte y pueden usar programas automatizados para encontar su clave. <item> ¿Como activo shadow passwords en mi Linux Red Hat 4.2 o 5.0 ? Respusta: Shadow password es un mecanismo para almacenar sus claves en otro fichero distinto al habitual /etc/passwd. Esto tiene varias ventajas. La primera es que el fichero donde se guardan, /etc/shadow, sólo lo puede leer el root mientras que /etc/passwd tiene que permanecer con permiso de lectura para todos. Otra ventaja es que como administrador, puede activar o desactivar cuentas sin que nadie sepa el estado de los otros usuarios. El fichero /etc/passwd se usa entonces para almacenar usuario y nombre de grupos, usados por programas como `/bin/ls' para aplicar el ID al nombre de usuario adecuado en un listado de un directorio. El fichero /etc/shadow por tanto sólo contiene el nombre de usuario u su clave, y quizás información administrativa, como cuando expira la cuenta, etc. Para activar shadow passwords, ejecute 'pwconv' como root, y su /etc/shadow se creará, y será usado por las aplicaciones. Como usa RH 4.2 o superior, los módulos PAM se adaptarán automáticamente a la modificación de cambiar el uso de /etc/passwd normal a shadow passwords sin otro cambio. Como está interesado en asegurar sus claves, quizás estaría interesado en generar claves buenas para empezar. Para esto puede usar el módulo `pam_cracklib' que es parte de PAM. Este módulo ejecuta su clave con las librerías Crack para ayudarle a decidir si es demasiado fácil de adivinar por programas de ruptura de claves. <item> ¿Como activo la extensiones Apache SSL? Respuesta 1.Consiga SSLeay 0.8.0 o posterior de ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL 2.Constrúyalo, verifique e instálelo 3.Consiga las fuentes de Apache 1.2.5 4.Consiga las extensiones Apache SSLeay de <url url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz" name="here"> 5.Desempaquételo en el directorio fuente de apache-1.2.5 y parchee Apache según el README. 6.Configure y constrúyalot. También puede intentar <htmlurl url="http://www.replay.com" name="Replay Associates"> que tiene muchos paquetes preconstruidos y está fuera de EE.UU. <item> ¿Cómo puedo manipular las cuentas de usuario, y seguir manteniendo la seguridad? Respuesta: La distribución Red Hat, especialmente RH5.0, contiene un gran número de herramientas para cambiar las propiedades de las cuentas de los usarios. <itemize><item> Los programas pwconv y unpwconv se pueden usar para convertir y en y restaurar las shadow passwd. <item>Los programas pwck grpck se pueden usar para verificar la correcta organización de lso ficheros passwd y group <item> El programa useradd, usermod, y userdel se pueden usar para añadir, modificar y borrar cuentas de usuario. Los programas groupadd, groupmod, y groupdel hacen lo mismo para grupos. <item>Las claves de grupos se pueden crear con gpasswd. </itemize> Todos estos programas funcionan con shadow passwd, esto es, si activa shadow, usaran /etc/shadow para la inforamción de las claves, y si no, no. Vea las respectivas páginas del manual para una mayor información. <item> ¿Cómo puedo proteger con clave documetos HTML específicos usando Apache? Apuesto que no conoce <htmlurl url="http://www.apacheweek.com" name="http://www.apacheweek.org"> ¿Verdad? Puede encontar información sobre Autenticidad de Usuarios en <htmlurl url="http://www.apacheweek.com/features/userauth" name="http://www.apacheweek.com/features/userauth"> también como otros trucos de servidores web de <htmlurl url="http://www.apache.org/docs/misc/security_tips.html" name="http://www.apache.org/docs/misc/security_tips.html"> </enum>  <sect> Conclusión Suscribiéndose a las listas de correo de alertas de seguridad, y estando al día, puede avanzar en la seguridad de su máquina. Si presta atención a sus ficheros de registro y ejecuta regularmente algo como tripwire puede incluso conseguir más. Un nivel razonable de seguridad del equipo no es difícil de mantener en sistema doméstico. En máquinas de negocios se requieren más esfuerzos, pero Linux puede ser una plataforma segura. Debido a la naturaleza del desarrollo de Linux, las correcciones de seguridad llegan mucho más rápido que en los sistema operativos comerciales, haciendo de Linux una plataforma ideal cuando se requiere seguridad.  <sect> Agradecimientos La información recogida aquí es recopilada de muchas fuentes. Gracias a quienes indico a continuación, que directa o indirectamente han contribuido: <tscreen><verb> Rob Riggs <rob@DevilsThumb.com> S. Coffin <scoffin@netcom.com> Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu> Roelof Osinga <roelof@eboa.com> Kyle Hasselbacher <kyle@carefree.quux.soltec.net> "David S. Jackson" <dsj@dsj.net> "Todd G. Ruskell" <ruskell@boulder.nist.gov> Rogier Wolff <R.E.Wolff@BitWizard.nl> </verb></tscreen> <!-- - - - - - - - - - - - - - - - - - - - - - - - - - -

Linux Security HOWTO <author>Kevin Fenzi, <tt>kevin@scrye.com</tt>&ero Dave Wreski, <tt>dave@nic.com</tt> Traducido por Pedro Pablo Fábrega <tt>pfabrega@arrakis.es</tt> <date>v0.9.11, 1 May 1998 <abstract> Este documento es una revisión general de las características de seguridad que tiene que tener en cuenta el administrador de un sistema Linux. Cubre la filosofía general de seguridad y cierto número de ejemplos específicos sobre como mejorar la seguridad de su sistema linux frente a intrusos. También se incluyen referencias sobre material y programas relacionados con la seguridad. OBSERVACIÓN: Esta es una versión beta del documento. Se agradecen las mejoras, críticas constructivas, añadidos y correcciones. Debido a mi filtro anti spam, necesitará una clave para enviarme correo. Lo siento. Para evitar esto incluya en la línea "subject" de su mensaje, "linux", "security" o "HOWTO". </abstract> <toc>  <sect> Introducción Este documento trata de cubrir parte de las principales características que afectan a la seguridad de linux. Se discutirán la filosofía general y los nuevos recursos de red. Otros COMOS se pueden solapar con ciertas características de seguridad, y esos han sido indicados donde se consideraba apropiado. Este documento no pretende ser una lista de actualización de programas que afectan a la seguridad (exploits). Continuamente aparecen programas de este tipo. Este documento le podrá indicar donde buscar una información actualizada de ese tipo, y algunos métodos generales para prevenir que esos programas tengan éxito.  <sect1> Nuevas versiones de este documento Las nuevas versiones de este documento se enviarán periódicamente a <it>comp.os.linux.answers</it>. También se añadir ftp anónimos que contienen información de este tipo, incluyendo: <tt> <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO" name="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO"> </tt> Además, normalmente podrá encontrar este documento en la página principal de Linux Worldwide Web mediante: <tt> <htmlurl url="http://sunsite.unc.edu/mdw/linux.html" name="http://sunsite.unc.edu/mdw/linux.html"> </tt> Finalmente, la última versión de este documento también debería estar disponible en varios formatos en: <tt> <htmlurl url="http://scrye.com/~kevin/lsh/" name="http://scrye.com/~kevin/lsh/"> </tt>  <sect1> Revisión Todos los comentarios, errores, información adicional y críticas de todo tipo se deberían dirigir a: <tt> <htmlurl url="mailto:kevin@scrye.com" name="kevin@scrye.com"> </tt> OBSERVACIÓN: Uso un filtro antispam para todo mi correo. Esto significa que si no lo conozco, su correo rebotará con una nota para que me lo reenvíe con una clave adecuada en la cabecera "subject". Comprendo el problema que esto ocasiona, pero desde que recibo entre 20 y 30 mensajes de spam diarios he tenido que hacer algo. Por favor, vuelva a enviar su mensaje con la clave en el campo subject y entonces leeré su correo. También puede evitar este paso estando seguro de poner "linux" "security" o "HOWTO" en el motivo ("subject") de su mensaje. <tt> <htmlurl url="http://scrye.com/~kevin/" name="http://scrye.com/~kevin/"> </tt>  <sect1> Descargo No se acepta ningún tipo de responsabilidad por los contenidos de este documento. Utilice los conceptos, ejemplos y otros contenidos bajo sus propios riesgo y responsabilidad. Adicionalmente, esta es una versión de las primeras, con muchas posibilidades de inexactitudes y errores. Cierto número de ejemplos y descripciones utilizan el esquema de la distribución RedHat(tm) y su sistema de configuración. En su distribución puede ser diferente. Hasta donde yo sé, sólo se describirán los programas, que bajo ciertas condiciones, pueden ser usados o evaluados para propósitos personales. La mayoría de los programas están disponibles de forma completa con las fuentes bajo términos parecidos a GNU.  <sect1> Información de Copyright Este documento es propiedad intelectual de (copyrighted) (c)1998 Kevin Fenzi y distribuido bajo las siguientes condiciones: <itemize> <item> Los documentos Linux HOWTO (COMO) se pueden reproducir y distribuir completos o en parte, por cualquier medio físico o electrónico, siempre que esta condición de copia se mantenga en todas las copias. La distribución comercial está permitida y fomentada; sin embargo al autor le gustaría que se le notificasen cualquiera de estas distribuciones. <item> Todas las traducciones, trabajos derivados o trabajos agregados tienen que estar cubiertos por esta nota de copyright. Esto es, NO puede realizar un trabajo derivado de un HOWTO (COMO) e imponer restricciones adicionales a su distribución. Se pueden ofrecer excepciones a estas reglas bajo ciertas condiciones; por favor póngase en contacto con el coordinador de HOWTO en la dirección de más abajo. <item> Si tiene alguna cuestión, por favor póngase en contacto con Greg Hankins, el coordinador de Linux HOWTO en </itemize> <tt> <htmlurl url="mailto:gregh@sunsite.unc.edu" name="gregh@sunsite.unc.edu"> </tt>   <sect1> ¿Por qué Necesitamos Seguridad? El cambio cotidiano del mundo de las comunicaciones de datos, las conexiones baratas a internet y el rápido desarrollo del software, la seguridad se está convirtiendo en una cuestión más y más importante. Ahora, la seguridad es un requisito básico, ya que la red global en insegura por definición. Mientras sus datos vayan del punto A al B por internet, por ejemplo, puede pasar por otros puntos durante el camino dando a otros usuarios la posibilidad de interceptarlos, e incluso alterar los datos. Incluso otros usuarios de su sistema pueden transformar datos de forma maliciosa para algo que no nos interese. Los intrusos, también conocidos como <it>crakers</it> pueden obtener acceso no autorizado usando unos conocimientos avanzados para hacerse pasar por vd. y robar su información e incluso denegarle el acceso a sus propios recursos. Si todavía se está preguntando la diferencia entre un <it>"Hacker"</it> y un <it>"Cracker"</it>, vea el documento de Eric Raymond, <it>"How to Become A Hacker"</it> (Como convertirse en un <it>Hacker</it>), disponible en <htmlurl url="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html" name="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html">.  <sect1> ¿Como de Seguro es Seguro? Primero, tenga en cuenta que ningún sistema es "completamente" seguro. Todo lo que puede hacer es aumentar la dificultad para que alguien pueda comprometer a su sistema. Para el conocimiento de los usuarios de Linux en casa, no se necesita demasiado para mantener alejados a los <it>crackers</it> casuales. Para los usuarios de Linux muy personallizados (bancos, compañías de telecomunicaciones, etc), se necesita mucho más trabajo. Otro factor a tener en cuenta es cuanto más seguro es su sistema más intrusiva se hace la seguridad. Necesita decidir donde está el equilibrio entre la facilidad de uso de su sistema y su seguridad. Por ejemplo, puede necesitar que cualquiera que llame por el módem a su sistema, nuestro módem tenga que devolver la llamada a su número de casa. Esto es más seguro, pero si alguien no está en casa, le hace más difícil conectarse. Podría poner su sistema Linux sin conexiones de red o a internet, pero esto le dificulta moverse por la web. Si es un sitio medio-grande, habrá establecido una "Política de Seguridad" que fije el nivel de seguridad que requiere ese sitio y que sistema de comprobación se realiza. Puede encontrar un ejemplo muy conocido de política de seguridad en <htmlurl url="http://ds.internic.net/rfc/rfc2196.txt" name="http://ds.internic.net/rfc/rfc2196.txt">. ha sido actualizado recientemente y contiene una gran estructura en la que basar la política de seguridad de su compañía.  <sect1> ¿Qué Está Tratando de Proteger? Antes de intentar asegurar su sistema debería determinar contra qué nivel de amenaza quiere protegerse, qué riesgo acepta o no y como resultado como de vulnerable es su sistema. Debería analizar su sistema para saber qué está protegiendo, por qué está protegiendo, qué valor tiene y quienes tienen responsabilidad de sus datos y otras cosas. <itemize><item> Riesgo es la posibilidad de que un intruso pueda intentar acceder con éxito a su equipo. ¿Puede un intruso leer y escribir en ficheros o ejecutar programas que puedan causar daño?¿Pueden borrar datos críticos? ¿Prevenir a su compañía de la pérdida de un trabajo importante realizado? Recuerde, alguien está que obteniendo acceso a su cuenta, o su sistema, también puede hacerse pasar por vd. Además, teniendo una cuenta insegura en su sistema, puede verse comprometida toda su red. Un simple usuario al que se le permita presentarse al sistema usando un fichero rhost, o permitir el uso de un servicio inseguro como tftp, origina el riesgo de que los intrusos puedan usarlo para "meter un puerta". Una vez que el intruso tiene una cuenta de usuario en su sistema, o en el sistema de cualquier otro, puede usarla para conseguir acceso a otros sistemas o a otras cuentas. <item> La amenaza proviene de alguien que tiene motivos para obtener acceso sin autorización a su red o equipo. Debe decidir en quien confía para tener acceso a su sistema y que amenaza puede representar. Las amenazas proceden de varios tipos de intrusos, y es útil tener en mente sus diferentes características cuando esté asegurando sus sistemas. <itemize> <item><bf>El Curioso</bf> - Este tipo de intruso está interesado básicamente interesado en qué tipo de sistema y datos tiene. </item> <item><bf>El Malicioso</bf> - Este tipo de intruso está fuera para bien hacerle caer su sistema, modificar su página web o cualquier otra cosa que le cueste tiempo y dinero recuperar. </item> <item><bf>El Intruso muy Personalizado</bf> - Este tipo de intruso trata de usar su sistema para ganar popularidad o mala fama. Puede usar su sistema para promocionar sus habilidades. </item> <item><bf>La Competencia</bf> - Este tipo de intruso está interesado en los datos que tiene en su sistema. Puede ser alguien que piense que tiene algo que le puede interesar financieramente o de otra forma. </item> </itemize><item> La vulnerabilidad describe como de bien protegido está su equipo frente a otra red, y el potencial para alguien que pueda obtener acceso no autorizado. ¿Qúe está en juego si alguien entra en su sistema? Desde luego será distinto para un usuario en casa con un enlace PPP dinámico que para las compañías que conectan su máquina a internet u otra gran red. ¿Cuanto tiempo me llevaría recuperar/recrear cualquier dato que se ha perdido? Una inversión en tiempo ahora puede ahorrar diez veces más de tiempo con posterioridad si tiene que recrear los datos que se perdieron. ¿Ha verificado su estrategia de copias de respaldo, y ha verificado sus datos últimamente? </itemize>  <sect1> Desarrollo de una Política de Seguridad Cree una política simple y genérica para su sistema, para que sus usuarios la puedan entender con facilidad y seguir. Esto debería proteger los datos que pretende poner a salvo y también la privacidad de sus usuarios. Algunos detalles que tiene que considerar adicionalmente quienes tienen acceso al sistema (¿pueden usar la cuenta mis amigos?), a quien se le permite instalar programas en el sistema, quien es el propietario de determinados datos, métodos de recuperación de pérdidas y uso apropiado del sistema. Una política de seguridad generalmente aceptada empieza con esta frase: <quote><bf>"Todo lo que no está permitido, está prohibido"</bf></quote> esto significa que, salvo que garantice acceso a un servicio para un usuario, el usuario no debería usar ese servicio hasta que no le ofrezca el acceso. Esté seguro de que las políticas funcionan en su cuenta regular de usuario, diciendo "Ah, no tengo permiso para resolver este problema, lo tendré que hacer como root", le puede llevar a descubrir agujeros de seguridad que son bastante obvios, e incluso otros que no han sido utilizados aun.  <sect1> Medios de la Seguridad de su Sitio Este documento discutirá varios medios mediante los cuales puede asegurar los recursos por los que tanto ha trabajado: su equipo local, datos, usuarios, red, incluso su reputación. ¿Qué sucedería con su reputación si un intruso borra los datos de uno de sus usuarios? ¿O alguien retoca sus páginas web? ¿O se publican los planes de su compañía para los próximos meses? Si está planeando una instalación de red hay muchos factores que debe tener en cuenta antes de añadir una simple máquina a su red. Incluso si tiene una simple cuenta telefónica PPP, o un pequeño sitio, esto no significa que los intrusos no estén interesados en sus sistemas. No sólo los sitios grandes y muy personalizados son los objetivos, muchos intrusos simplemente quieren explotar tantos sitios como les sea posible, sin importar su tamaño. Además, pueden usar agujeros de seguridad de su sitio para obtener accesos a otros sitios a los que vd. se conecte. Los intrusos tienen mucho tiempo a su disposición, y pueden evitar preguntarse como ha protegido su sistema con sólo intentar todas las posibilidades. Hay también varias razones más por las que un intruso puede estar interesado en su sistema, que se discutirá más tarde.  <sect2> Seguridad del Host Quizás el área donde se concentra más seguridad es en la seguridad basada en hosts. Típicamente implica estar seguro de que su sistema es seguro, y esperar que todas las demás personas de la red hagan lo mismo. Escoger buenas claves, asegurar los servicios de red de su host, mantener un buen registro de cuentas y actualizar los programas que tienen exploits conocidos que afectan a su seguridad, son las cosas de las que es responsable el administrador local. Aunque esto es absolutamente necesario, se puede convertir en una complicada labor si su red se hace muy grande.  <sect2> Seguridad de su Red La seguridad de la red es tan necesaria como la seguridad de un host. Con su simple sistema, o una red distribuida, internet o cientos, sino miles de equipos en la misma red, no puede tener la confianza de que todos esos equipos son seguros. Estando seguro de que sólo se le permite acceso a su red a usuarios autorizados, construyendo cortafuegos, usando cifrados fuertes, asegurándose de que no hay pícaros, o máquinas inseguras en su red, todo esto son parte de las preocupaciones y deberes del administrador de una red segura. Este documento discutirá alguna de las técnicas usadas para asegurar su sitio, y espero mostrar algunas formas para prevenir que un intruso obtenga acceso a lo que está tratando de proteger.  <sect2> Seguridad mediante Oscuridad Un tipo de seguridad que se debe discutir es "seguridad mediante oscuridad". Esto significa que haciendo algo como cambiar el nombre de conexión de 'root' a 'toor', por ejemplo, para intentar confundir a alguien que intenta entrar en sus sistema como root, es sólo una falsa sensación de seguridad, y puede originar unas consecuencias muy desagradables. Descanse seguro de que cualquier atacante de sistemas rápidamente se dará cuenta de esas mediadas de seguridad vacías. Por el hecho de que tenga un sitio pequeño o de relativamente bajo nivel de personalización, no significa que un intruso no esté interesado en lo que tiene. Discutiremos en próximas secciones lo que está protegiendo.   <sect> Visión General Este documento intentará explicar algunos procedimientos y programas usados con frecuencia para ayudar a mantener su sistema linux más seguro. Lo primero que tenemos que tener en mente es que no existe nada como un sistema completamente seguro. Todo lo que puede hacer es aumentar la dificultad para que alguien pueda comprometer su sistema. En el caso medio del usuario de linux en casa, no se requiere demasiado para mantener alejado al <it>cracker</it>. Para usuarios con grandes requisitos (bancos, compañías de telecomunicaciones, etc) se requiere mucho más trabajo. Otro factor a tener en cuenta es que cuanto más incremente la seguridad de su sistema, más intrusiva se vuelve la seguridad. Necesita decidir en que medida su sistema es utilizable y en que medida es seguro para sus propósitos. Por ejemplo, puede necesitar que cualquiera marque a su modem para que este devuelva la llamada a su casa. Esto es más seguro, pero si alguien no está en casa hace más difícil que se pueda conectar. También puede configurar su sistema linux sin conexión a internet, pero esto dificulta que pueda navegar por las webs. Si tiene un sitio medio-grande, debería establecer una "Política de Seguridad" que indique qué niveles requiere su sitio y qué medidas de evaluación se realizan. Este documento ha sido segregado en varias secciones. Contempla varios tipos de características de seguridad. El primero, seguridad física, contempla como tiene que proteger físicamente su máquina de ataques. El segundo describe como proteger su sistema del ataque de sus usuarios locales. El tercero, la seguridad en redes, describe como mejorar la seguridad de su sistema linux ante los ataques desde una red. El siguiente discute qué hacer cuando detecta que su sistema está siendo comprometido o ha detectado un recientemente. Después se enumeran una serie de enlaces hacia otros recursos de seguridad y por último una palabras de despedida. Los dos puntos principales de los que se tiene que dar cuenta cuando lea este documento son: <itemize> <item> Tenga cuidado con su sistema. Verifique los registros (logs) del sistema, tales como /var/log/messages y no pierda de vista su sistema , y <item> Dos, tenga su sistema actualizado, estando seguro de que ha instalado las versiones actuales de los programas y esté al tanto de las nuevas alertas de seguridad. Haciendo esto, le ayudará a hacer que su sistema sea mucho más seguro. </itemize>  <sect> Seguridad Física La primeras medida de seguridad que necesita tener en cuenta son las de seguridad física de sus sistemas. ¿Quien tiene acceso físico directo a su máquina? ¿Debería? ¿Puede proteger sus m sus ataques? ¿Debería protegerlas? El grado de seguridad física que necesita en su sistema depende en mucha medida de su situación, por supuesto. Si es un usuario doméstico probablemente no necesite demasiada protección, aunque le puede interesar proteger su máquina de un niño u otros problemas similares. Si está en un entorno de laboratorio o similar, necesitará un grado considerablemente mayor de seguridad, pero los usuarios necesitarán realizar y obtener el trabajo realizado en las máquinas. Muchas de las siguientes secciones nos ayudar Si está en una oficina, puede que necesite o no, mantener su máquina segura durante horas o mientras esté fuera. En algunas compañías, dejar su consola insegura puede ser motivo de despido. Obviamente los métodos de seguridad física tales como bloqueo de puertas, cables, o vigilancia por vídeo, son buenos métodos, pero no son para tratarlos en este documento. :)  <sect1> Bloqueo del equipo La mayoría de los PC modernos incluyen características de bloqueo. Normalmente habrá una cerradura en la caja que le permite, mediante una llave, ponerlo en posición de bloqueado o desbloqueado. En algunos casos puede prevenir la apertura de la caja y la manipulación del hardware. También puede ser una protección para que alguien arranque el equipo con su propio disquete u otro hardware. Estos bloqueos hacen diferentes cosas de acuerdo a las prestaciones de la placa base y de la fabricación de la caja. En muchos equipos hay que romper la caja para abrir el equipo. En otros, lo que hace es bloquear el teclado y el ratón de forma que no pueda teclear nada ni usar el ratón. Mire las prestaciones que le ofrece su placa base para tener más información. Esto puede ser útil en muchas ocasiones una característica útil, incluso cuando los cierres son de poca calidad y se pueden abrir con facilidad con un destornillador u otra herramienta. En algunos casos (de forma notable en sparcs y macs) tienen la posibilidad de ponerle un candado lo que dificulta notablemente el robo de su equipo.  <sect1> BIOS Security La BIOS es el nivel más bajo de seguridad mediante software que gestiona el hardware basado en los x86. LILO y otros métodos de arranque acceden a la BIOS para determinar como iniciar su máquina Linux. En otro hardware, bajo el que también funciona Linux tienen un software similar (OpenFirmware en macs y nuevos suns, sun boot prom, etc...). Puede usar la BIOS para prevenir que los atacantes reinicien su máquina y manipulen su sistema Linux. Muchas BIOS bajo linux/x86 le permiten incluir clave de acceso. Esto no proporciona excesiva seguridad (se puede reiniciar la BIOS o eliminar, si alguien abre la caja), pero puede ser otro elemento disuasorio (i.e. llevará más tiempo y dejará más pistas de la manipulación). Otras muchas BIOS de los x86 también le permiten especificar otras varias medidas de seguridad. Compruebe el manual de la BIOS o mire la próxima vez que reinicie el equipo. Algunos ejemplos son: desactivar reinicio desde el disquete, y claves para acceder a ciertas características de la BIOS. En Linux/Sparc, la eeprom SPARC se puede fijar para que solicite una clave en el arranque. Esto puede ralentizar el ataque. OBSERVACIÓN: Si tiene una máquina servidora, y tiene una clave para el arranque, la máquina no se reiniciará sin atención. Tenga en cuenta que necesitará acudir e introducir la clave en el caso de un corte de corriente. ;-(  <sect1> Seguridad en el arranque Los distintos cargadores de linux también tienen una clave de inicio. Si usa lilo, déle un vistazo a los parámetros "restricted" y "password". "password" le permite incluir una clave para la carga. "restricted" le permitir iniciar la máquina salvo que alguien especifique opciones en el indicador LILO: (como 'single'). Tenga en mente cuando configure todas estas claves que necesitará recordarlas. :) También recuerde que estas claves sólo ralentizan al atacante que tiene la deteterminación de hacerlo. Si alguien tiene información relativa a otros métodos diferentes de arranque, me gustaría oír de ellos. (grub, silo, milo, linload, etc). OBSERVACIÓN: NOTE: Si tiene una máquina servidora, y tiene una clave para el arranque, la máquina no se reiniciará sin atención. Tenga en cuenta que necesitará acudir e introducir la clave en el caso de un corte de corriente. ;-(  <sect1> xlock y vlock Si se aleja de su máquina de vez en cuando, estaría bien poder bloquear su consola para que nadie pueda manipularla o mirar su trabajo. Dos programas que hacen esto son xlock y vlock. Xlock blquea la pantalla. Se debería incluir en cualquier distribución de Linux que soporte X. Mire la página de manual para ver más, pero en general puede ejecutar xlock desde cualquier xterm de su consola y bloqueará la pantalla de forma que necesita su clave para desbloquearla. vlock es simple programita que le permite cerrar alguna o todas las consolas virtuales de su máquina linux. Puede bloquear sólo en la que está trabajando o todas. Si sólo cierra una, las otras se pueden abrir y utilizar la consola, pero no se podrá usar su vty hasta que no la desbloquee. vlock viene con RedHat, pero su situación puede ser diferente. Desde luego, bloquear una consola, prevendrá que alguien manipule su trabajo, pero no previene de reinicios de la máquina u otras formas de deteriorar su trabajo.  <sect1> Detección de problemas de seguridad física Lo primero que tiene que observar es cuando se reinició su máquina. Como Linux es un S.O. robusto y estable, las causas que le obligan a reiniciar el sistema es actualizar el S.O., el hardware o similares. Si su máquina se reinició sin que vd. lo sepa, cabe la posibilidad de un problema. Muchas de los métodos para comprometer la seguridad de su máquina requieren que el intruso reinicie o apague su máquina. Busque signos del ataque en la caja y por el área del ordenador. Aunque muchos intrusos borran las huellas de su presencia, es una buena idea comprobarlos y observar cualquier discrepancia. Algunas cosas para comprobar en sus registros (logs): <itemize> <item>Registros cortos o incompletos. <item>Registros con fecha y hora extraños. <item>Registros con permisos o propietarios incorrectos. <item>Registro de carga de reinicio del sistema o de otros servicios. <item>Registros perdidos. <item>Entradas su o logins desde lugares extraños. </itemize> Donde buscar los ficheros de registro, dependerá de su distribución. En RedHat estdrá que mirar en /var/log y comprobar messages, mail.log y otros. También le puede interesar configurar el guión (script) de rotación de registros o el demonio que mantiene los registros hasta un determinado tamaño para que le de tiempo a examinarlos. Échele un vistazo al paquete logrotate de las distribuciones recientes de RedHat. Otras distribuciones probablemente tendrán procesos similares.  <sect> Seguridad Local Lo siguiente que tiene que mirar es la seguridad de su sistema frente a los ataques de los usuarios locales. ¿Dije usuarios locales? Sí. Una de las primeras cosas que un intruso intenta es obtener acceso como usuario local. Con una seguridad local laxa, pueden "actualizar" su acceso normal como usuario a acceso como root utilizando una serie de deficiencias (bugs) y configuraciones pobres de los servicios locales. Si está seguro de su seguridad local, el intruso tendrá otro obstáculo que saltar. Los usuarios locales también pueden causar un montón de estragos con su sistema incluso (especialmente) si son realmente quienes dicen que son. Proporcionar cuentas a personas desconocidas o con las que no tiene información de contacto es muy mala idea. Antes de cambiar los permisos de cualquier sistema de ficheros, esté seguro de que entiende lo que está haciendo. Nunca cambie los permisos de un fichero sólo porque parezca una forma fácil de hacer que las cosas funcionen. Determine siempre por qué el fichero tiene ese permiso antes de cambiarlo.  <sect1> Creación de nuevas cuentas Debe estar seguro y proporcionar cuentas de usuario sólo con los requisitos mínimos para el trabajo. Si le crea una cuenta a su hijo, de 10 años, le puede interesar que sólo tenga acceso a un procesador de textos o un programa de dibujo, pero que no pueda hacer un rm de todo. Aquí tiene varias buenas reglas para cuando permita a otros un acceso legítimo a su máquina: <itemize> <item> Déle solo la mínima cantidad de privilegios que necesita. <item> Tega cuidado con donde/cuando se conecta o si se debería conectar. <item> Esté seguro de eliminar aquellas cuentas que ya no son necesarias. </itemize> Muchas de las cuentas de usuarios locales que se usan para comprometer la seguridad de su sistema, son las que no han sido utilizadas en meses o años. Como nadie las usa proporcionan el vehículo ideal para un ataque. <sect1> Seguridad del root Otro atacante local frecuente es el administrador del sistema linux. (Sí, vd.). Recuerde que sólo debe usar la cuenta de root para tareas específicas y cortas y el resto hacerlo como usuario normal. Ejecutar como root todo el tiempo es una idea muy muy mala. Use su o sudo para realizar las tareas que necesite. Varios trucos para evitar que pueda estropear su propio Linux como root: <itemize> <item> Cuando vaya a ejecutar un comando complejo, intente primero ejecutarlo de una forma no destructiva, especialmente los comandos con comodines. Por ejemplo, si quiere hacer un "rm foo*.bak", haga primero : "ls foo*.bak" y compruebe realmente los ficheros que va a borrar. También puede usar echo en algunas circunstancias. <item> Algunas personas encuentran útil hacer un "touch /-i" en sus sistemas Esto hará que comandos como "rm -rf *" le pregunten primero si realmente quiere borrar todos esos ficheros. ( Esto lo hace la shell, resolviendo primero el "-i" y tratándolo como la opción -i de rm). Esto no nos será útil con comandos rm sin *. <item> El comando path es importante para el usuario root. El comando path o la variable de entorno PATH define la busqueda de programas por la shell. Intente limitar tanto como sea posible el comando path para el usuario root, y nunca use '.', (directorio actual) en su PATH. Además, no tenga directorios con permiso de escritura en su ruta de búsquedas, ya que esto puede permitir a los atacantes modificar o poner nuevos binarios que se pueden ejecutar como root la próxima vez que ejecute el comando. <item> Nunca use la suit de herramientas rlogin/rsh/rexec (llamadas las r-utilidades) como as root. Puede ser objeto de diversos tipos de ataques y es peligroso ejecutarlas como root. Nunca cree un fichero .rhosts para root. <item> El fichero /etc/securetty contiene la lista de terminales desde las cuales se puede conectar el root. Por defecto (en Linux RedHat) se incluyen sólo las consolas virtuales (vtys). Tenga mucho cuidado al añadir otra cosa a este fichero. Debería poder presentarse al sistema de forma remota como un usuario normal u entonces usar su si lo necesita (mejor sobre ssh u otro canal cifrado) con lo cual no tiene necesidad de entrar directamente como root. <item> Cambie a root sólo para realizar tareas específicas simples. si tiene la necesidad de hacer algo, inténtelo en una shell de usuario normal hasta que esté <bf>seguro</bf> de qué hay que hacer como root. <item> Actúe de forma lenta y meditada cuando sea root. Sus acciones podrían afectar a un montón de cosas. ¡Piénselo antes de antes de teclear! </itemize> Si de forma inevitable tiene que permitir a alguien (espero que de mucha confianza) hacerse root en su máquina, hay algunas herramientas que le pueden ayudar. Sudo permite a los usuarios utilizar sus claves para acceder a un limitado número de comandos como root. Esto le permitiría, por ejemplo, permitir a un usuario montar y desmontar dispositivos removibles en su linux, pero sin tener otros privilegios. sudo también mantiene un registro de todos los intentos y éxitos, permite seguir la pista de los usuarios con los comandos y quor esta razón sudo funciona bien incluso en situaciones donde un determinado núemero de usariso tienen acceso de root, pero usan sudo para que se pueda tener un rastro de los cambios realizados.  <sect> Ficheros y Seguridad del Sistema de Archivos Unos pocos minutos de preparación y planificación antes de conectar su sistema le puede ayudar a proteger su sistema y los datos que tiene almacenados en él. <itemize> <item> No debería haber ninguna razón para que los directorios home de los usuarios permitieran que programas SUID/SGID se ejecutaran desde allí. Use la opción `nosuid' en /etc/fstab para las particiones que tienen permiso de escritura por alguien distinto de root. También le puede interesar usar `nodev' y `noexec' en las particiones de los directorios home de los usuarios. También en /var, lo que prohibe la ejecución de programas y creación dispositivos de bloque o carácter, que en ningún caso serían necesarios. <item> Si exporta sistemas de archivos vía NFS, esté seguro de configurar /etc/exports con los accesos lo más restrictivos posibles. Esto significa no usar plantillas, no permitir acceso de escritura a root y montar como sólo lectura siempre que sea posible. <item> Configura la máscara de creación de ficheros para que sea lo más restrictiva posible. Son habituales 022, 033, y la más restictiva 077, y añadirla a /etc/profile. <item> Ponga el límites al sistema de archivos en lugar de 'ilimitado' como está por defecto. Puede controlar el límite por usuario utilizando el módulo PAM de límite de recursos y /etc/pam.d/limits.conf. Por ejemplo, los límites para un grupo `users' podría parecer a esto: <tscreen><verb> @users hard core 0 @users hard nproc 50 @users hard rss 5000</verb></tscreen> Esto dice que se prohiba la creación de ficheros core, restringe el número de procesos a 50, y restringe el uso de memoria por usuario a 5M. <item> Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios de su sistema. Se debe mantener su integridad ya que determinan cuando y de donde entró en su sistema un usario o un potencial intruso. Los ficheros deberían tener los permisos 644, sin afectar a la normal operación del sistema. <item> El bit inmutable se puede usar para prevenir borrados accidentales o proteger un fichero para sobreescritura. También previene que alguien cree enlaces simbólicos a un fichero, que ha sido el origen de ataques basados en el borrados de los ficheros /etc/passwd o /etc/shadow. Vea la página del manual de chattr(1) para tener más información sobre el bit inmutable. <item> Los ficheros SUID y SGID de su sistema son potenciales riesgos de seguridad y deberían ser controlados. Como estos programas garantizan privilegios especiales al usuario que los ejecuta, es necesario estar seguro que no hay instalados programas inseguros. Un truco favorito de los crackers es explotar programas con el bit SUID, y entonces dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso aunque el agujero original ya esté tapado. Encuentre todos los programas SUID/SGID de su sistema y mantener la pista de lo que son, para que esté prevenido de cualquier cambio que podría indicar un potencial intruso. Use el siguiente comando para localizar todos los progrmas SUID/SGID en su sistema: <tscreen><verb> root# find / -type f \( -perm -04000 -o -perm -02000 \) </verb></tscreen> Puede eliminar los permisos SUID o SGIG de un programa con chmod(1), y siempre puede devolverlo a su estado original si piensa que es absolutamente necesario. <item> Los ficheros con permiso de escritura global, particularmente los del sistema, pueden ser un agujero de seguridad si un cracker obtiene acceso a su sistema y los modifica. Además los directorios con permiso de escritura global son peligrosos ya que permiten a un cracker añadir y borrar los ficheros que quiera. Para localizar los ficheros con permiso de escritura global, use el siguiente comando: <tscreen><verb> root# find / -perm -2 -print </verb></tscreen> y esté seguro de saber por qué tienen esos permisos de escritura. En el curso normal de una operación ficheros tendrán permisos de escritura, incluidos algunos de /dev y enlaces simbólicos. <item> Los ficheros sin propietario también pueden ser un indicio de que un intruso ha accedido a su sistema. Puede localizar los ficheros de su sistema que no tienen propietario o que no pertenecen a un grupo con el comando: <tscreen><verb> root# find / -nouser -o -nogroup -print </verb></tscreen> <item> La localización de ficheros .rhosts debería ser una de los deberes de la administración de su sistema regular, ya que estos ficheros no se deberían permitir en sus sistema. Recuerde que un cracker sólo necesita una cuenta insegura para potencialmente obtener acceso a toda su red. Puede localizar todos los ficheros .rhosts de su sistema con el siguiente comando: <tscreen><verb> root# find /home -name .rhosts -print </verb></tscreen> <item> Finalmente, antes de cambiar permisos en cualquier sistema de ficheros, esté seguro de que entiende lo que hace. Nunca cambie permisos de un fichero simplemente porque parezca la forma fácil de hacer una cosa. Siempre debe determinar porqué el fichero tiene esos permisos antes de modificarlos. </itemize>  <sect1>Estado de umask El comando umask se puede usar para determinar el modo de creación de ficheros por defecto en su sistema. Es el complemento octal a los modos de fichero deseado. Si los ficheros se crean sin ningún miramiento de estado de permisos, el usuario, de forma inadvertida podrá asignar permisos de lectura o escritura a alguien que no debería tenerlo. De forma típica, el estado de umask incluye 022, 027 y 077, qque es lo más restrictivo. Normalmente umask se pone en /etc/profile y por tanto se aplica a todos los usuarios del sistema. Por ejemplo, puede tener una línea parecida a la siguiente: <tscreen><verb> # Pone el valor por defecto de umask del usuario umask 033 </verb></tscreen> Esté seguro de que el valor umask de root es 077, lo cual desactiva los permisos de lectura, escritura y ejecución para otros usuarios, salvo que explícitamente use chmod(1). Si está usando Red Hat, y se adhiere a su esquema de creación de ID de grupos y usuarios (User Private Groups), sólo es necesario usar 002 para umask. Esto se debe al hecho de que la configuración por defecto incluye un grupo por usuario.   <sect1> Permisos de ficheros Es importante asegurarse que sus ficheros de sistema no los abren los usuarios o grupos que no tienen que realizar tareas de mantenimiento del sistema por ediciones casuales. UNIX separael control de acceso a ficheros y directorios de acuerdo con tres características: propietario, grupo y otros. Siempre hay un sólo propietario, todos los miembros del grupo y cualquier otro. Una rápida explicación de los permisos Unix: Propiedad: -Qué usuario(s) y grupo(s) retiene el control de los permisos del nodo y del padre del nodo. Permisos - Bits que se pueden fijar para permitir ciertos tipos de acceso a él. Los permisos para directorio pueden tener un significado diferente a los permisos para ficheros. Lectura (r): <itemize> <item>Poder ver los contenidos de un fichero <item>Poder leer un directorio </itemize> Escritura (w): <itemize> <item>Poder modificar o añadirle a un fichero <item>Poder borrar o mover ficheros en un directorio </itemize> Ejecución(x): <itemize> <item>Poder ejecutar un programa binario <item>Poder buscar en un directorio </itemize> Usted - El propietario del fichero Group - El grupo al que pertenece Everyone - Cualquiera del sistema <descrip> <tag/Save Text Attribute: (Para directorios)/ El sticky bit también tiene un significado diferente cuando se aplica a directorios. Si es sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son propiedad del usuario o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios. </descrip> <descrip> <tag/Attributo SUID: (Para Ficheros)/ Este describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso (no el usuario que lo lanza). Esto es causa de la utilización de muchos 'buffer overflow'. </descrip> <descrip> <tag/Atributo SGID: (Para ficheros)/ Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto. </descrip> <descrip> <tag/Atributo SGID: (Para directorios)/ Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio. </descrip> Usted - El propietario del fichero Grupo - El grupo al que vd. pertenece Otros - Cualquiera del sistema que no sea propietario o miembro del grupo. <tscreen><verb> Ejemplos: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - ¿directorio? (no) 2nd bit - ¿lectura por el propietario? (si, por kevin) 3rd bit - por el propietario? (si, por kevin) 4th bit - ¿ejecución por el propietario? (no) 5th bit - ¿lectura por el grupo? (sí, por users) 6th bit - ¿escritura por el grupo? (no) 7th bit - ¿ejecución por el grupo? (no) 8th bit - ¿lectura por cualquiera? (si, por cualquiera) 9th bit - ¿escritura por cualquiera? (no) 10th bit - ¿ejecución por cualquiera? (no) </verb></tscreen> Las siguientes líneas son ejemplos del conjunto mínimo de permisos que se requieren para llevar a cabo el acceso descrito. Puede querer dar más permisos que los listados, pero esto debería describir que hacen esos permisos mínimos sobre los ficheros: <tscreen><verb> -r-------- Permite acceso de lectura al propietario --w------- Permite al propietario modificar o borrar el fichero ---x------ El propietario puede ejecutar este programa, pero no scripts de shell que requieren permisos de lectura ---s------ Se ejecutará con usuario efectivo ID = propietario -------s-- Se ejecutará con usuario efectivo ID = grupo -rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap) ---t------ No tiene efecto. (antes sticky bit) </verb></tscreen> <bf>Ejemplo de Directorio:</bf> <tscreen><verb> drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - ¿directorio? (si, contiene muchos ficheros) 2nd bit - ¿lectura por el propietario? (si, por kevin) 3rd bit - por el propietario? (si, por kevin) 4th bit - ¿ejecución por el propietario? (sí, por kevin) 5th bit - ¿lectura por el grupo? (sí, por users) 6th bit - ¿escritura por el grupo? (no) 7th bit - ¿ejecución por el grupo? (sí, por users) 8th bit - ¿lectura por cualquiera? (si, por cualquiera) 9th bit - ¿escritura por cualquiera? (no) 10th bit - ¿ejecución por cualquiera? (sí, por cualquiera) </verb></tscreen>  </verb></tscreen> Las siguientes líneas son ejemplos del mínimo conjunto de permisos que se requieren para llevar a cabo el acceso descrito. Le puede interesar dar más permisos que los indicados, pero esto debería describir que hacen los permisos mínimos en los directorios: <tscreen><verb> dr-------- El contenido se puede listar pero no se pueden leer los atributos. d--x------ Se puede entrar en el directiorio y usado en las rutas de ejecución completas. dr-x------ Se pueden leer los atributos del fichero por el propietario. d-wx------ Se pueden crear/borra ficheros, incluso si no es el actual. d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp d---s--s-- No tiene efecto </verb></tscreen> Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca deje algún fichero del sistema con permiso de escritura por un grupo o por cualquiera. Algunos ficheros de configuración, incluyendo, /etc/shadow, sólo deberían tener permiso de lectura por root, y los directorios de /etc no deberías ser accesibles, al menos por otros. <descrip> <tag /SUID Shell Scripts/ Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razón el núcleo no los acepta. Sin importar lo seguro que piense que es su script de shell, puede ser utilizado para que un cracker pueda obtener acceso a una shell de root. </descrip>  <sect1> Verificar la integridad con Tripwire Una forma cómoda de detectar ataques locales (y también de red) en sus sistema es ejecutar un programa que verifique la integridad como Tripwire. Tripwire ejecuta varios cheksums de todos los binarios importantes y ficheros de configuración y los compara con una base de datos con valores de referencia aceptados como buenos. Así se detecta cualquier cambio en los ficheros. Es buena idea instalar tripwire en un disquete y protegerlo físicamente. De esta forma no se puede alterar tripwire o modificar su base de datos. Una vez que tripwire se ha configurado, es buena idea ejecutarlo como parte de de los deberes habituales de administración para ver si algo ha cambiado. Incluso puede añadir una entrada a crontab para ejecutar tripwire desde su disquete todas las noches y enviar por correo los resultados y verlos por la mañana, Algo como esto: <tscreen><verb> # set mailto MAILTO=kevin # run tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire </verb></tscreen> le enviará por correo un informe cada mañana a las 5:15am. Tripwire puede ser un "don divino" para detectar intrusos antes de que tenga otro tipo de noticias de ellos. Como son muchos los ficheros que se modifican en su sistema, debería tener cuidado con lo que es la actividad de un cracker y lo que es la activiadad normal del sistema.  <sect1> Caballos de Troya El nombre de Caballo de Troya se debe al símil que se establece con los hechos contados por Homero en la Iliada. La idea es poner un programa binario, que parece genial, y consigue que otras personas lo carguen y lo ejecuten como root. Entonces puede comprometer la seguridad de su sistema mientras no se presta atención. Mientras se piensa que el binario que hemos lanzado hace algo (que puede estar bien), también puede estar saltándose la seguridad. Debería tener cuidado con qué programas instala en su máquina. Redhat proporciona md5 checksums y ficheros firmados con pgp para pueda verificar que está instalando algo real. Otras distribuciones disponen de métodos similares. Jamás debería ejecutar un binario del cual no tiene las fuentes o sabe perfectamente qué programa es. Algunos atacantes también están publicando código fuente para que se pueda realizar un uso público y aprovecharse de ello. Aunque esto puede ser complicado, debería asegurarse que obtiene las fuentes de un programa de el sitio real de su distribución. Si el programa se va a ejecutar como root, tendría que estar seguro que alguien de su confianza ha revisado y verificado el programa.  <sect1> Seguridad de Claves & y Cifrado (Encryption) Unas de las más importantes características de seguridad usadas hoy son ls claves. Es importante para todos, usted y sus usuarios, tener claves seguras insospechadas. La mayoría de las distribuciones Linux recientes incluyen programas 'passwd' que no permiten a los usuarios poner claves fácilmente adivinables. Esté seguro de que su programa passwd está actualizado y tiene estas características. Está fuera de los objetivos de este documento una discusión en profundidad sobre cifrado, pero daremos una introducción. El cifrado (encriptado) es muy útil, posiblemente incluso necesario en estos días. Hay distintos métodos de cifrar datos, cada uno con sus propios inconvenientes. Debería estar prevenido con algunos de los más comunes. cifrado de claves unix: La mayoría de los unix (y linux no es una excepción) usan DES (Data Encryption Standard) para cifrar sus claves. Estas claves cifradas se almacenan (típicamente) en /etc/passwd o (con menos frecuencia ) en /etc/shadow. Cuando intenta presentarse al sistema, todo lo que teclea se cifra de nuevo y comparado con la entrada correspondiente del fichero /etc/passwd. Si coinciden, debe ser la misma clave y se le permite el acceso. DES en un algoritmo de cifrado de una sola vía. DES tiene reputación de débil en estos días de ordenadores rápidos. Ataques a la fuerza bruta, como crack o John de ripper (ver abajo), con frecuencia pueden adivinar claves salvo que su clave sea lo suficientemente aleatoria. Los módulos PAM (ver abajo) permiten usar rutinas de cifrado diferentes con sus claves (MD5 o parecidas).  <sect1> PGP y Clave de Cifrado Pública (Public Key Cryptography) Public Key Cryptography, tal y como se usa por PGP, implica un cifrado que usa una clave para cifrar y otra para descifrar. Tradicionalmente, el cifrado implica el uso de la misma clave para descifrar que la que se usó para cifrar. Esta "clave privada" se debe conocer por ambas partes y de alguna forma, transferirse de uno a otro de forma segura. La clave de cifrado pública alivia la necesidad de asegurar la transmisión de la clave usada para el cifrado usando dos claves separadas, una pública y otra privada. Cada clave pública de una persona está disponible por cualquiera para realizar el cifrado, mientras que a la misma vez cada persona mantiene su clave privada para descifrar el mensaje cifrado con la correspondiente clave pública. Hay ventajas con las claves de cifrado públicas y privadas y puede informarse de las diferencias en las FAQ de RSA Cryptography indicadas al final de esta sección. PGP (Pretty Good Privacy) está muy bien soportada por Linux. Las versions 2.6.2 y 5.0 se sabe que funcionan bien. Para iniciarse en PGP y como usarlo mire las PGP FAQ. <htmlurl url="http://www.pgp.com/service/export/faq/55faq.cgi" name="http://www.pgp.com/service/export/faq/55faq.cgi"> Esté seguro de usar la versión que es aplicable a su país, ya que debido a las restricciones del gobierno de EE.UU, los cifrados fuertes se consideran armas militares y se prohibe su transferencia electrónica fuera del país. También hay una guía paso a paso para configurar PGP en Linux, disponible en <htmlurl url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html" name="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"> Fue escrito para la versión Internacional de PGP. (pero es fácilmente adaptable a la versión EE.UU). Puede que necesite un parche para alguna de las últimas versiones de Linux, disponible en <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/crypto" name="ftp://sunsite.unc.edu/pub/Linux/apps/crypto">. Podemos encontrar más indormación sobre cifrado en RSA cryptography FAQ, disponibles en <htmlurl url="http://www.rsa.com/rsalabs/newfaq/" name="http://www.rsa.com/rsalabs/newfaq/">. Aquí encontrará información sobre términos como "Diffie-Hellman", "public-key cryptography", "Digital Certificates", etc.  <sect1> SSL, S-HTTP, HTTPS y S/MIME Con frecuencia los usuario preguntan las diferencias entre los distintos protocolos de seguridad y cifrado, y como se usan. Como esto no es un documento sobre cifrdo, es buena idea explicar brevemente qué es cada cosa y donde encontrar más información. <itemize> <item><bf>SSL:</bf> - SSL, o Secure Sockets Layer, es un método de cifrado desarrollado por Netscape para proporcionar seguridad en Internet. Soporta varios protocolos diferentes de cifrado y proporciona un servidor de verificación de clientes. SSL funciona a nivel de transporte, creando un canal seguro de datos cifrados y así puede cifrar datos de diversos tipos. Esto se ve con frecuencia cuando vamos a un sitio seguro para ver documentación en línea con Comunicatos y sirve como base para comunicaciones seguras con Comunicator, también como muchos Se puede encontrar más información en <htmlurl url="http://www.consensus.com/security/ssl-talk-faq.html" name="http://www.consensus.com/security/ssl-talk-faq.html">. Otras implementaciones de seguridad de Netscape y un buen punto de partida para estos protocolos se puede encontrar en <htmlurl url="http://home.netscape.com/info/security-doc.html" name="http://home.netscape.com/info/security-doc.html">. <item><bf>S-HTTP:</bf> - S-HTTP es otro protocolo que proporciona servicios de seguridad sobre internet. Fue diseñado para proporcionar servicios seguros a través de internet. Fue diseñado para proporcionar confidencialidad, autenticidad, integridad y no repudiabilidad &lsqb no se puede confundir con nadie] mientras que soporta mecanismos de gestión de múltiples claves y algoritmos de cifrado mediante opción de negociación entre las partes implicadas en cada transacción. S-HTTP está limitado al software específico que implementa y cifra cada mensaje individualmente &lsqb de RSA Cryptography FAQ, página 138] <item><bf>S/MIME:</bf> - S/MIME, o Secure Multipurpose Internet Mail Extension, es un cifrado estándar utilizado para cifrar correo electrónico u otros tipos de mensajes sobre internet. Es un desarrollo estándar abierto de RSA, por tanto existe la esperanza de que con probabilidad lo veremos en Linux pronto. Se puede encontrar más información sobre S/MIME en <htmlurl url="http://home.netscape.com/assist/security/smime/overview.html" name="http://home.netscape.com/assist/security/smime/overview.html">. </itemize>  <sect1> Implementación Linux x-kernel IPSEC Con CIPE, y otras formas de cifrado de datos, hay también una implementación de IPSEC para Linux. IPSEC es un trabajo de IETF para crear comunicaciones cifradas seguras a nivel de red IP, lo que proporciona autenticidad, integridad, control de acceso y cofidencialidad. Se puede encontrar información sobre IPSEC en <htmlurl url="http://www.ietf.org/html.charters/ipsec-charter.html" name="http://www.ietf.org/html.charters/ipsec-charter.html">. También puede encontrar enlaces con otros protocolos que implican gestión de claves y la lista de correo de IPSEC y sus archivos. La implementación de Linux, que estásiendo desarrollada en la Universidad de Arizona, usa una estructura basada en objetos para implementar protocolos de red llamados x-kernel, y se puede encontrar en <htmlurl url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html" name="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html">. De forma más simple, x-kernel es u método de pasar mensajes al nivel del núcleo, que hace una más fácil implementación. Como con las otras formas de cifrado, no se distribuye con el núcleo por defecto, debido a restricciones de exportación.  <sect1> SSH (Secure Shell), stelnet SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y tener una conexión cifrada. SSH es un conjunto de programas usados como sustitución segura de rlogin, rsh y rcp. Usa claves públicas de cifrado para cifrar las comunicaciones entre dos hosts, también como para la verificación de claves. Esto se puede usar para asegurar las conexiones a un host remoto o copiar datos entre hosts, mientras que previene los ataques en el intermedio (secuestro de sesión) y falsificación de DNS (DNS spoofing). Realizará una conexión de los datos de su conexión y asegura las comunicaciones X11 entre hosts. La página principal de SSH, se puede encontrar en <htmlurl url="http://www.cs.hut.fi/ssh/" name="http://www.cs.hut.fi/ssh/"> También puede usar SSH desde su estación de trabajo Windows hacia su servidor SSH Linux. Hay varias implementaciones de clientes Windows de libre disposición, incluyendo el que hay en <htmlurl url="http://guardian.htu.tuwien.ac.at/therapy/ssh/" name="http://guardian.htu.tuwien.ac.at/therapy/ssh/"> y también implementaciones comerciales de DataFellows, en <htmlurl url="http://www.datafellows.com" name="http://www.datafellows.com">. SSLeay es un implementación libre del protocolo Secure Sockets Layer de Netscape, que incluye varias aplicaciones, tales como Secure telnet, un módulo para Apache, varias bases de datos como varios algoritmos incluyendo DES, IDEA y Blowfish. Al usar esta biblioteca, se ha creado un telnet seguro que realiza cifrado sobre las conexiones telnet. A diferencia de SSH, stelnet usa SSL, el protocolo Secure Sockets desarrollado por Netscape. Puede encontrar Secure telnet y Secure FTP empezando con las FAQ SSLeay disponibles en <htmlurl url="http://www.psy.uq.oz.au/~ftp/Crypto/" name="http://www.psy.uq.oz.au/~ftp/Crypto/">  <sect1> PAM - Pluggable Authentication Modules Las nuevas versiones de la distribución Red Hat Linux vienen con un esquema de verificación uinificado llamado "PAM". PAM le permite cambiar sobre la marcha los métodos de verificación, requisitos y encapsular todos los metodos de verificación sin recompilar ninguno de los binarios. La configuración de PAM va más allá de los objetivos de este documento pero asegúrese de echarle un vistazo a la web de PAM para una mayor información <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/index.html" name="http://www.kernel.org/pub/linux/libs/pam/index.html"> Sólo algo de lo que puede hacer con PAM: <itemize> <item> Usa un cifrado no DES para sus claves. (Haciendo más difícil descifrarlas por la fuerza bruta). <item> Pone límite a los recursos sobre todos los usuarios para que no puedan realizar un ataque de denegación de servicios (número de procesos, cantidad de memoria, etc). <item> Activa shadow passwords (ver abajo) sobre la marcha <item> permite a usuarios específicos conectar sólo a horas específicas desde lugares específicos. </itemize> Con unas pocas horas de instalación y configuración de su sistema puede prevenir muchos ataques antes de que ocurran. Por ejemplo, use PAM para desactivar los ficheros rhost del sistema (generales o de punto) en los directorios home de los usuarios añadiendo estas líneas a /etc/pam.d/login: <tscreen><verb> # # Desactivae rsh/rlogin/rexec para usaurios # login auth required pam_rhosts_auth.so no_rhosts </verb></tscreen>  <sect1>Cryptographic IP Encapsulation (CIPE) El primer objetivo de este software es proporcionar facilidades para asegurar (contra escuchas, incluyendo análisis de tráfico e inyección de mensajes falsos) en comunicaciones entre subredes a través de una red de paquetes inseguros como es Internet. CIPE cifra los datos a nivel de red. El viaje de los paquetes entre hosts se hace cifrado. La máquina de cifrado está situada cerca del driver que envía y recibe los paquetes. Esto es, a diferencia de SSH que cifra los datos por conexión, a nivel de socket. Así un conexión lógica entre programas que se ejecutan en hosts diferentes está cifrada. CIPE se puede usar en tunnelling parrr crear una Red Virtual Privada. El cifrado a bajo nivel tiene la vantaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningún cambio en el software de aplicación. Sumario de documentación CIPE : El estándar IPSEC define un conjuntos de protocolos que se pueden usar (entre otras cosas) para construir RVP. Sin embargo, IPSEC es un protocolo más complicado con un montón de opciones implementadas en todo el protocolo que raramente se usan y algunas características (como gestión de claves) que no están completamente resueltas. CIPE usa una simple aproximación, en la cual muchas cosas que se pueden parametrizar (como la elección del algoritmo actual de cifrado usado) se elijen 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 ...). Se puede encontrar más información en <htmlurl url="http://www.inka.de/~bigred/devel/cipe.html" name="http://www.inka.de/~bigred/devel/cipe.html"> Como otras formas de cifrado, esto no se distribuye con el núcleo por defecto debido a restricciones a la exportación.  <sect1> Kerberos Kerberos ees un método de verificación desarrollado por el Athena Project en el MIT. Cuando un usuario se conecta, la Kerberos verifica que es el usuario (usando clave), y proporciona el usario con una forma de probar su identidad a otros servidores y hosts dispersos en la red. Esta verificación se usa por programas como rlogin para permitir al usuario conectarse a otros hosts sin clave (en lugar del fichero rhosts) . La verificación también se usa por el sistema de correo para garantizar que el correo se entrega a la persona correcta, como también garantizar que el remitente es quien dice ser. El efecto global de instalar Kerberos y los numerosos programas que van el él, es eliminar virtualmente la posibilidad de que un usuario haga "spoof" en el sistema, creyendo que es otro. Desafortunadamente, la instalación de Kerberos es muy entrometida, y requiere la modificación o sustitución de numerosos programas estándar. Puede encontrar más información sobre kerberos en <htmlurl url="http://www.veritas.com/common/f/97042301.htm" name="http://www.veritas.com/common/f/97042301.htm"> y el código se puede encontar en <htmlurl url="http://nii.isi.edu/info/kerberos/" name="http://nii.isi.edu/info/kerberos/"> [From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]  <sect1> Shadow Passwords. Shadow passwords es un sistema para mantener sus claves cifradas secretas para los usuarios normales. Normalmente estas claves cifradas se almacenan en su fichero /etc/passwd que tiene lectura pública. Esto facilita que alguien pueda ejecutar programas para averiguar las claves en un intento de determinarlas. Shadow passwords guardan su información en el fichero /etc/shadow que sólo se puede leer con privilegios de superusuario. Para ejecutar shadow passwords tiene que estar seguro de que todas las utilidades que necesitan el acceso a la información de claves están compiladas con para soportar PAM (arriba) también le permite poner un módulo shadow y no requiere la recompilación de ejecutables. Se puede dirigir al Shadow-Password HOWTO para más información si es necesario. Está disponible en <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html" name="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"> Está actualizado ahora y no será necesario para distribuciones que soporten PAM.  <sect1> Crack y John the Ripper Si por alguna razón su programa passwd no fuerza claves fuertes le puede interesar ejecutar un programa para romper claves y estar seguro de que las claves son seguras. Los programas para la rotura de claves funcionan a partir de una idea simple. Intentan todas las palabras del diccionario y después variaciones sobre estas palabras. Cifra cada un de estas palabras y la compara con la clave cifrada. Si coinciden la hemos encontrado. Hay varios programas, los más notables son "Crack" y "John the Ripper" <htmlurl url="http://www.false.com/security/john/index.html" name="http://www.false.com/security/john/index.html"> . Consumen un montón de tiempo de CPU, pero deberían decirle si un atacante podría obtener las claves y después notificárselo a los usuarios con una clave débil. Observe que un atacante primero tendría que usar otro agujero para conseguir las claves cifradas (el fichero unix /etc/passwd), pero esto es más frecuente de lo que podría pensar.  <sect1> CFS - Cryptographic File System y TCFS - transparent cryptographic File System CFS es una forma de cifrar un sistema de ficheros completo y permitir a los usuarios almacenar ficheros cifrados en ellos. Si usa un servidor NFS corriendo en la máquina local, hay rpms disponibles en <htmlurl url="http://www.replay.com/redhat/" name="http://www.replay.com/redhat/"> y más información sobre como funciona en: <htmlurl url="ftp://ftp.research.att.com/dist/mab/" name="ftp://ftp.research.att.com/dist/mab/"> TCFS es una mejora sobre CFS, añadiendo más integración con el sistema de ficheros, de forma que es transparente a cualquier usuario que use el sistema de ficheros que está cifrado. Más información en: <htmlurl url="http://edu-gw.dia.unisa.it/tcfs/" name="http://edu-gw.dia.unisa.it/tcfs/" >  <sect1> X11, SVGA and display security  <sect2> X11 Es importante asegurar su salida gráfica para prevenir que los atacantes hagan cosas como: grabar sus claves mientras las introduce, sin que lo sepan, leer documentos o información que tiene en la pantalla, o incluso usar un agujero para obtener acceso de superusuario. La ejecución remota de aplicaciones X sobre la red también puede ser llenada con peligro, permitiendo que los espías (sniffers) vean toda su interacción con el sistema remoto. X tiene cierto número de mecanismos de control. El más simple es el basado en el host. Puede usar xhost para especificar a qué hosts se les acceder a su display. Esto no es muy seguro de todas formas. Si alguien tiene acceso a su máquina puede hacer xhost + su máquina y entrar fácilmente. También, si tiene que permitir acceso de una máquina insegura cualquiera puede comprometer su display. Cuando use (x display manager) para entrar al sistema, tiene un método mucho mejor de acceso: MIT-MAGIC-COOKIE-1. Se genera un cookie de 128bit y se almacena en su fichero .Xauthorty. Si necesita permitir acceder a su display a una máquina remota, puede usar el el comando xauth y la información de fichero .Xauthority para proporcionar acceso a esa conexión. Vea el mini-howto Remote-X-Apps disponible en <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html">. También puede usar ssh (vea ssh arriba) para permitir conexiones X seguras. Esto tiene la ventaja de ser también transparente al usuario final, y significa que no circulan por la red datos descifrados. Mire la página de manual de Xsecurity para mas información sobre la seguridad en X. La mejor apuesta es usar xdm para conectarse a su consola y entonces ssh para ir a los sitios remotos en los que quiere ejecutar aplicaciones.  <sect2> SVGA Los programas de SVGAlib son típicamente SUID-root para poder acceder a todo su hardware de video de su máquina Linux. Esto los hace muy peligrosos. Si fallan, típicamente necesita reiniciar su máquina para tener una consola utilizable. Esté seguro de que cualquier programa SVGA que ejecuta es auténtico, y que al menos se puede confiar. Incluso mejor, no los ejecute.  <sect2> GGI (Generic Graphics Interface project) El proyecto Linux GGI está intentando resolver varios problemas con los interfaces de de video sobre Linux. GGI moverá una pequeña parte del código de video al núcleo de Linux y entonces controlar el acceso al sistema de video. Esto significa que GGI podrá restaurar su consola en cualquier momento a un estado bueno conociso. También permitirá una clave de atención segura para que pueda estar seguro que no hay ningún caballo de Troya de login ejecutándose en su consola. <htmlurl url="http://synergy.caltech.edu/~ggi/" name="http://synergy.caltech.edu/~ggi/">  <sect> Seguridad del Núcleo Esto es una descripción de las opciones de configuración del núcleo que están relacionadas con la seguridad y una explicación de lo que hace y como usarlo. Como el núcleo controla la red de su equipo, es importante que el núcleo sea muy seguro, y que el mismo núcleo no pueda ser comprometido. Para prevenir algunos de los últimos ataques de red, debe intentar mantener una versión del núcleo actualizada. Puede encontrar los nuevos núcleos en ftp://ftp.kernel.org.  <sect1> Opciones de Compilación del Núcleo <itemize> <item>IP: Drop source routed frames (CONFIG_IP_NOSR) Esta opción debería estar activada. Source routed frames contienen la ruta completa de sus destinos dentro del paquete. Esto significa que los enrutadores a través de los que circula el paquete no necesitan inspeccionarlo, y sólo lo reenvían. Esto podría llevar a que los datos que entran a su sistema puedan ser un exploit potencial. <item>IP: Firewalling (CONFIG_IP_FIREWALL) Esta opción es necesaria si va a configurar su máquina como un cortafuegos, hacer enmascaramiento o desea proteger su estación de trabajo con línea telefónica de qeu alguien entre a través de su interfaz PPP. <item>IP: forwarding/gatewaying (CONFIG_IP_FORWARD) Si activa reenvío IP (IP forwarding), su caja Linux esencialmente se convierte en un encaminador (router). Si su máquina está en una red, podría estar enviando datos de una red a otra, y quizás subvirtiendo un cortafuegos que esté puesto allí para evitar que esto suceda. Los usuario normales de conexión telefónica les interesará desactivar esto y otros usuarios se deberían concentrar en las implicaciones de seguridad de hacer esto. Las máquinas cortafuegos querrán esto activada y usarlo en conjunción con el software de cortafuegos. Puede activarr y desactivar el reenvío IP (IP forwarding) dinámicamente usando el siguiente comando: <tscreen><verb> root# echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> y desactivarlo con el comando: <tscreen><verb> root# echo 0 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> Ese fichero (y muchos otros ficheros de /proc) aparecerán con longitud cero, pero de echo no lo son. Esto es una nueva característica introducida, por lo que tiene que tener un núcleo 2.0.33 o posterior. <item>IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) Esta opción le da información sobre los paquetes que su cortafuegos recibe, como remitente, recipiente, puerto, etc. <item>IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) Generalmente esta opción está desactivada, pero si esta construyendo un host cortafuegos o apra enmascaramiento, deberá activarla. Cuando se envía de un host a otro, no siempre se envía como un simple paquete de datos, sino que se fragmenta en varios trozos. El problema de esto es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que alguien puede insertar información en el resto de los paquetes para su conexión que se supone que no deberían estar allí. <item>IP: syn cookies (CONFIG_SYN_COOKIES) El ataque SYN es un ataque de denegación de servicio (denial of service DoS) que cosume todos los recuroso de su máquina forzando un reinicio. No podemos encontrar ninguna razón por la que no debiera activar esto. <item>Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) Esta es ua opción disponible en los núcleos de la serie 2.1 que firmarán los paquetes NCP para una mayor seguridad. Normalmente puede dejarlo desactivado, pero está allí por si lo necesita. <item>IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) Esta es un hábil opción que le permite analizar los primeros 128 bytes de los paquetes en el espacio de programa de usuario, para determinar si le gustaría aceptar o denegar el paquete basado en su validez. </itemize>  <sect1> Dispositivos del Núcleo Hay algunos dispositivos de bloque y carácter disponibles en Linux que también ayudarán con la seguridad. Los dos dispositivos /dev/random y /dev/urandom los proporciona el núcleo para recuperarar datos aleatorios en cualquier instante. Ambos, /dev/random y /dev/urandom deberían ser suficientemente seguros como para generar claves PGP, SSH y otras aplicaciones donde son un equisito números aleatorios seguros. Los atacantes no podrían ser capaces de determinar el siguiente número dada cualquier secuencia de números con este origen. Se han puesto muchos esfuerzos para asegurar que los números que obtiene de esta fuente son aleatorios en todos los sentidos de la palabra aleatorio. La única diferencia es que /dev/random suministra bytes aleatorios y le hace esperar para que se acumulen más. Observe que en algunos sistemas puede bloquear durante un rato a la espera de que se genere una nueva entrada de usuario al sistema. Por tanto debe tener cuidado al usar /dev/random. (Quizás lo mejor que puede hacer es usarlo cuando esté generando información sensible de claves e indicarle al usuario que pulse una tecla repetidas veces hasta que indique por la pantalla "OK, es suficiente"). /dev/random tiene gran calidad e entropía, midiendo tiempos entre interrupciones etc. Bloquea hasta que hay dispoibles suficientes bits de datos aleatorios. /dev/urandom es parecido, no es tan seguro, pero suficiente para la mayoría de las aplicaciones. Puede leer los dispositivos usando algo parecido a lo siguiente: <tscreen><verb> root# head -c 6 /dev/urandom | uuencode - </verb></tscreen> Esto imprimirá seis caracteres aleatorios en la consola, válidos para la generación de una clave. Vea /usr/src/linux/drivers/char/random.c para obtener una descripción del algoritmo. Gracias a Theodore Y. Ts'o, Jon Lewis, y otros del Linux-kernel por ayudarme (Dave) con esto.  <sect> Seguridad de Red La seguridad en redes se está volviendo más y más importante ya que la gente pasa cada vez más tiempo conectada. Comprometer la seguridad de una red es con frecuencia más fácil que hacerlo con la física o local, y mucho más frecuente. Hay un gran número de herramientas para ayudar con la seguridad de una red y mucha información que viene con las distribuciones de Linux.  <sect1> Espías de paquetes (Packet Sniffers) Una de las formas más frecuentes que tienen los intrusos para obtener acceso a más sistemas de su red es usar un espía de paquetes (sniffer) en un host que ya ha sido comprometido. Este "sniffer" escucha en los puertos Ethernet cosas como "Password", "Login" y "su" en el flujo de paquetes y registra el tráfico posterior. De esta forma los atacantes obtienen claves de sistemas que ni siquiera tratan de atacar. Las claves enviadas sin cifrar son muy vulnerables a estos ataques. EJEMPLO: El host A ha sido comprometido. Los atacantes instalan un sniffer. El sniffer recoge los logind del administrador en el host B desde el host C. Consigue las claves personales de los administradores mientras entran en B, entonces el administrador hace un su para corregir un problema. Ahora tienen la clave del root del host B. Más tarde el administrador deja a alguien hacer telnet desde su cuenta al host Z en otro sistio. Ahora el atacante tiene el par password/login en el host Z. En este momento el atacante no necesita ni comprometer el sistema para hacer esto, también podría traer un portátil o un pc al edificio y meterse en su red. El uso de ssh u otros métodos de claves cifradas impide este ataque. Cosas como APOP para cuentas pop también previene este ataque. (Los login pop normales son muy vulnerables en esto, como cualquier cosa que se envía en texto sin cifrar sobre la red).  <sect1> Servicios del sistema y tcp_wrappers Tan pronto como ponga su sistema en cualquier red, lo primero que tiene que mirar es qué servicios necesita ofrecer. Los servicios que no necesita ofrecer los debe desactivar para tener menos cosas de las que preocuparse por un ataque y tener un sitio menos para situar un agujero. Hay varias formas de desactivar servicios bajo Linux. Puede mirar en su fichero /etc/inetd.conf y ver qué servicios están siendo ofrecidos por su inetd. Desactivando los que no necesite comentándolos (# al principio de la línea), y después enviar a su proceso inetd una SIGHUP. También puede eliminar (o comentar) servicios en su fichero /etc/services. Esto significa que los clientes locales tampoco podrán encontrar el servicio si elimina ftp e intenta hacer un ftp a un sitio remoto de su máquina, fallará con un mensaje de servicio desconocido). Es normal no preocuparse de eliminar servicios ya que esto no proporciona ninguna seguridad adicional. Si una persona local quiere usar ftp, incluso aunque haya comentado, el haría su propio cliente que usa el puerto ftp común y funcionaría bien. Algunos servicios que querrá dejar activos son: <itemize><item>ftp <item>telnet <item>mail, como pop-3 o imap <item>identd <item>time </itemize> Si sabe que no va a utilizar algún paquete en particular, puede borrarlo entero, con rpm -e con la distribución Red Hat borrará el paquete entero. Bajo debian dpkg probablemente hace lo mismo. Además, quiere desactivar la utilidades rsh/rlogin/rcp, incluyendo login (usado por rlogin), shell (usado por rcp), y exec (usado por rsh) para que no sean iniciados en /etc/inetd.conf. Estos protocolos son extremadamente inseguros ya han sido causa de exploits en el pasado. Debería comprobar sus /etc/rc.d/rcN.d, donde N es su nivel de ejecución del sistema (systems run level) y ver si alguno de los servidores iniciados en esos directorios no son necesarios. Los ficheros de /etc/rc.d/rcN.d actualmente son enlaces simbólicos al directorio /etc/rc.d/init.d. Renombrar el fichero en el directorio init.d tiene el efecto de desactivar todos los enlaces simbólícos que hay en /etc/rc.d/rcN.d. Si sólo desea desactivar un servicio para un determinado nivel de ejecución, renombre el fichero adecuado con una 's' minúscula en lugar de la 'S' mayúscula como la de S45dhcpd. Si tiene los ficheros rc con el estilo BSD, tendrá que verificar /etc/rc* para los programas que no necesita. La mayoría de las distribuciones Linux vienen con tcp_wrappers que "cubren" todos sus servicios tcp. Un tcp_wrapper (tcpd) se llama desde inetd en lugar del servidor real. Tcpd comprueba entonces el host que solicita el servicio y bien ejecuta el servidor real o deniega el acceso de ese host. Tcpd permite restringir el acceso a sus servicios tcp. Debería crear un fichero /etc/hosts.allow y añadirle sólo aquellos host que necesitan tener acceso a los servicios de su máquina. Si es un usuario de línea telefónica en casa, le sugerimos que deniegue todo (ALL). tcpd también registra los intentos fallidos de acceder a un servicio, y así se puede hacer una idea de que está siendo atacado. Si añade nuevos servicios, debería estar seguro de configurarlos para usar tcp_wrappers. Por ejemplo, un usuario normal de conexión telefónica puede prevenirse de la conexiona a su máquina del exterior, y tener la posibilidad de recuperar correo y efectuar conexiones de red a internet. Para hacer esto podría añadir lo siguiente a su /etc/hosts.allow: ALL: 127. Y desde luego /etc/hosts.deny contendría: ALL: ALL lo que previene de conexiones externas a su máquina, y todavía le permite conectar a servidores de internet desde el interior.  <sect1> Verificar su Información DNS Mantener actualizada la información DNS sobre todos los hosts de su red le puede ayudar a aumentar la seguridad. En el caso de un host no autorizado se conecte a su red, puede reconocerlo por la ausencia de la entrada DNS. Muchos servicios se pueden configurar para no aceptar conexiones de hosts que carecen de entradas DNS válidas.  <sect1> identd identd es un pequño programa que se ejecuta desde su inetd. Mantiene la pista de qué usuario está ejecutando un determinado servicio tcp, e informa de ello cuando se le solicita. Mucha gente confunde la utilidad de identd, y en consecuencia lo desactiva o bloquea todos los sitios que lo solicitan. Identd no está ahí para ayudar a sitios remotos. No hay forma de conocer si los datos que que obtiene del identd remoto son correctos o no. No hay verificación de identidad en las solicitudes de identd. Enonces ¿por qué querría ejecutarlo? Porque le ayuda y es otra fuente de información. Si su identd no está alterado, entonces sabe que le está diciendo el usuario o uid de la gente de los sitios remotos que están usando los servicios tcp. Si el administrador de un sitio remoto viene y le dice que un usuario está intentando entrar (hack) en su sitio, entonces puede fácilmente tomar acciones contra ese usuario. Si no está ejecutando identd, tendrá que mirar un montón de registros para encontrar quien fue a determinada hora, y en general lleva mucho más tiempo encontrar la pista del usuario. El identd que viene con la mayoría de las distribuciones es más configurable de lo que mucha gente cree. Puede desactivar identd para determinados usuarios (pueden crear un fichero .identd), puede registrar todas las peticiones de identd (lo recomiendo) puede incluso tener a identd devolviendo un uid en lugar del nombre de usuario o incluso NO-USER.  <sect1> SATAN , ISS y otros Exploradores de Red Hay varios paquetes diferentes de software que efectúan una exploración basada en puertos y servicios de máquinas o de redes. SATAN y ISS son dos de los mejores conocidos. Este software se conecta con la máquina destino ( o todas las máquinas de la red) en todos su puertos que puede e intenta determinar qué servicio se está ejecutando allí. Basándose en esta información, podría descubrir si la máquina es vulnerable a un exploit específico en ese servidor. SATAN (Security Administrators Tool for Analyzing Networks) es un explorador de puertos con un interfaz web. Se puede configurar para efectuar verificaciones ligeras, medias o fuertes sobre una máquina o red, y fija los problemas que encuentra. Esté seguro de obtener una copia de SATAN de sunsite o un FTP o web con reputación. Había un copia Troyano de SATAN que se distribuía por la red. <htmlurl url="http://www.trouble.org/~zen/satan/satan.html" name="http://www.trouble.org/~zen/satan/satan.html"> ISS (Internet Security Scanner) hay otro explorador basado en puertos . Es más rápido que Satan y en consecuencia podría ser mejor para grandes redes. Sin embargo, SATAN tiende a proporcionar más información. Abacus-Sentry es un explorador de puertos comercial de www.psionic.com. Mire su página home en la web para más información. <htmlurl url="http://www.psionic.com" name="http://www.psionic.com"> Detecting Port scans. Hay algunas herramientas diseñadas para alertarle de pruebas con Satan, ISS y otro software de exploración. De todas formas el uso de tcp_wrappers y estando seguro de buscar en los ficheros regulares de registro debería notar tales pruebas. Incluso en el más bajo nivel, Satan aun deja trazas en los registros en un sistema Red Hat.  <sect1> Sendmail, qmail y MTA's. Uno de los servicios más importantes que puede proporcionar es el servidor de correo. Por desgracia, también es uno de los servicios más vulnerable a los ataques, simplemente debido al número de tareas que debe realizar y los privilegios que típicamente necesita. Si usa sendmail es muy importante mantener la versión actualizada Sendmail tiene una larga, larga historia de fallos de seguridad. Siempre esté seguro de usar la versión más reciente. <htmlurl url="http://www.sendmail.org/" name="http://www.sendmail.org"> Si está cansado de actualizaciones de su versión de sendmail cada semana debería plantearse cambiar a qmail. Qmail se diseñó teniendo en mente la seguridad desde principio a fin. Es más rápido, estable y seguro. <htmlurl url="http://www.qmail.org" name="http://www.qmail.org">  <sect1> Denegación de Servicios Un ataque de denegación de serviciso es uno en que el atacante intenta hacer que algún recurso esté demasiado ocupado para responder solicitudes legítimas o para denegar a los usuarios legítimos acceso a su máquina. Los ataques de denegación de servicios se han incrementado recientemente en los últimos años. Algunos de los más populares y recientes están listados abajo. Observe que aparecen nuevos continuamente, por tanto esto son sólo algunos ejemplos. Lea la lista de seguridad Linux y la lista bugtraq y archivos para una información más actualizada. <itemize><item> <bf>SYN Flooding</bf> - SYN flooding es un ataque de denegación de servicio de red. Se aprovecha de un agujero ("loophole") en la forma en que se crean las conexiones TCP. Los nuevos núcleos de Linux (2.0.30 y posteriores) tienen varias opciones configurables para prevenir ataques SYN flood que denieguen a la gente acceder a su máquina o servicios. Vea la sección de seguridad del núcleo para ver las opciones limpias de rotección del núcleo. <item><bf>Pentium "F00F" Bug</bf> - Recientemente se descubrió que una serie de código ensamblador enviado a un Pentium genuino reiniciabala máquina. Esto afecta a todas las máquinas con un procesador Pentium (no clones, no Pentium Pro o PII), no importa qué operación de sistema esté realizando. Los núcleos Linux 2.0.32 y superiores tienen un trabajo sobre este bug, previniendo que bloquee la máquina. El núcleo 2.0.33 tiene una versión mejorada de la corrección, sugerida sobre 2.0.32. Si está ejecutando un Pentium debería actualizarse ahora. <item> <bf>Ping Flooding</bf> - Ping flooding es un simple ataque de denegación de servicio por la fuerza bruta. El atacante envía una "inundación" (flood) de paquetes ICMP a su máquina. Si están haciendo esto desde un host con mayor ancho de banda que su máquina, será incapaz de enviar nada a la red. Una variante de esta ataque llamado "smurfing", envía paquetes ICMP a un host con la dirección IP de retorno de su máquina, permitiéndoles que la inundación sea menos detectable. Puede encontrar más información sobre ataques "smurf" en <htmlurl url="http://www.quadrunner.com/~chuegen/smurf.txt" name=" http://www.quadrunner.com/~chuegen/smurf.txt"> Si en alguna ocasión está bajo un ataque ping flood, use una herramienta como tcpdump para determinar de donde vienen los paquetes (o parece que vienen), entonces contacte con su proveedor con esta información. Los ping floods se pueden parar con más facilidad a nivel de encaminador o usando un cortafuegos. <item> <bf>Ping o' Death</bf> - El ataque Ping o' Death es el resultado de paquetes entrantes ICMP ECHO REQUEST que son más grandes que lo que pueden almacenar las estructuras de datos del núcleo que recogen esta información. Como enviar un simple paquete ping grande (65,510 bytes) "ping" a muchos sistemas, los cuelga o los rompe, este problema fue rápidamente resuelto. Este ha sido resuelto y ya no hay nada de qué preocuparse. <item> <bf>Teardrop / New Tear</bf> - Uno de los más recientes exploits que usan un bug presente en el código de fragmentación IP en plataformas Linux y Windows. Se corrigió en la versión del núcleo 2.0.33, y no requiere seleccionar ninguna opción de compilación del núcleo para usar la corrección. Linux aparentemente no es vulnerable al exploit 'newtear'. </itemize> Puede encontrar más código de exploits y más descripciones en profundidad de como funcionan en <htmlurl url="http://www.rootshell.com" name="http://www.rootshell.com"> usando su motor de búsqeda.  <sect1> Seguridad NFS (Network File System) NFS es un protocolo para compartir ficheros ampliamente utilizado. Permite a los servidores ejecutar nfsd y mountd para "exportar" sistemas de ficheros completos a otras máquinas con soporte de sistemas de ficheros nfs incorporado en el núcleo (u otro cliente que lo soporte si no son máquinas Linux). Mountd mantiene una pista de los sistemas de ficheros montados en /etc/mtab, y puede mostrarlos con 'showmount'. Muchos stios usan NFS para servir directorios home a sus usuarios, de forma que sin importar en qué máquina del grupo se conectan, tienen su directorio home y ficheros. Hay alguna parte de "seguridad " permitida al exportar sistemas de ficheros. Puede hacer que su nfsd mapee al usuario root remoto (uid=0) al usuario nobody, denegándole acceso total a los ficheros exportados. Sin embargo, como los usuario individuales tienen acceso sus propios ficheros (o al menos con el mismo uid), el superusuario remoto puede entrar en su cuenta y tener acceso total a sus ficheros. Esto es sólo un pequeño inconveniente para un atacante que tiene acceso para montar su sistema de ficheros remoto. Si tiene que usar NFS, esté seguro de que exporta sólo a aquellas máquinas que realmente necesita exportar. Nunca exporte su directorio raíz completo, exporte sólo los directorios que necesita exportar. Vea el NFS HOWTO para más información sobre NFS: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NFS-HOWTO.html" name="NFS HOWTO">  <sect1> NIS (Network Information Service) (conocido como YP). Network Information service (llamado YP) es un medio de distribuir información a un grupo de máquinas. El NIS principal recoge las tablas de información y las convierte en ficheros de mapas NIS. Estos mapas son servidos sobre la red, permitiendo a las máquinas NIS clientes conseguir login, claves, directorio home e información de shell (toda la información estándar del fichero /etc/passwd file). Esto permite a los usuarios cambiar sus claves una vez y que tenga efecto en todas las máquinas del dominio NIS. NIS no es del todo seguro. No nació para esto. Nació para ser útil y manejable. Cualquiera que puede averiguar el nombre de su dominio NIS (cualquiera de la red) puede obtener una copia del fichero passwd, y usar crack o john the ripper con las claves de usuarios. También es posible falsificar NIS y hacer toda clase de trucos sucios. Si tiene que uar NIS, esté seguro de que está prevenido de los peligros. Hay una sustitución de NIS mucho mas segura, llamada NIS+. Mire el NIS HOWTO para más información: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html">  <sect1> Cortafuegos (Firewalls) Los cortafuegos son medios de restringir qué información se permite que entre y salga de su red local. Normalmente el host cortafuegos está conectado a Internet y a su red local, y sólo se accede desde su red a internet a través del cortafuegos. Esta forma de cortafuegos puede controlar qué pasa y sale de internet y su red local. Hay diversas formas y métodos de activar un cortafuegos. La máquinas Linux pueden hacer cortafuegos a muy bajo coste. El código de los cortafuegos se puede construir con núcleos 2.0 y superiores. Las herramientas ipfwadm le permiten cambiar los tipos de tráfico de red que permite sobre la marcha. También puede registrar tipos de trafico particulares de la red. Los cortafuegos son muy útiles y es un técnica importante para asegurar su red. Es imoprtante darse cuenta que nunca debería pensar que como tiene un cortafuegos no necesita asegurar las máquinas que están detrás de él. Esto es un error fatal. Mire el Firewall-HOWTO en su último fichero en <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"> para más información sobre cortafuegos y Linux. More information can also be found in the IP-Masquerade mini-howto: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html" name="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"> Más información sobre ipfwadm (La herramienta que le permite cambiar el estado de su cortafuegos, la puede encontrar en su página home en: <htmlurl url="http://www.xos.nl/linux/ipfwadm/" name="http://www.xos.nl/linux/ipfwadm/">  <sect> Preparación para la Seguridad (antes de conectarse) Ha comprobado su sistema y ha determinado que es tan seguro como necesita y que está listo para conectarse. Hay unas cuantas cosas que debería hacer para prepararse en caso de una intrusión que actualmente suceden, de forma que rápidamente desactive al intruso y volver a funcionar.  <sect1> Hacer una Copia de Salvaguardia de su Máquina Las discusiones de los métodos de copias de salvaguardia está fuera de los objetivos de este documento, sólo unas pequeñas palabras relacionadas con copias de salvaguardia y seguridad. Si tiene menos de 650Mb de datos almacenados en una partición, una copia CD-R de sus datos es una buena forma de hacerlo (ya que es más difícil de falsificar con posterioridad, y si están almacenados de forma adecuada pueden durar mucho tiempo). Las cintas y otros medios sobre los que se puede escribir deberían protegerse tan pronto como se completa la copia y se verifica para evitar la falsificación. Tenga cuidado y almacene su copia de seguridad en un sitio seguro. Una buena copia de seguridad le asegura que tiene un buen punto desde el que restaurar su sistema.  <sect1> Escoger una Buena Secuencia de Copias Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta pra cada Viernes y una cinta para para los Viernes impares. Realice una copia incremental cada día, y una copia completa en la cinta adecuada de cada Viernes. Si hace algún cambio importante o añade datos importantes a su sistema también seríaadecuado efectuar una copia.  <sect1> Copiar su Base de Datos RPM o Debian En el caso de que un intruso entre en su sistema, puede usar su base de datos RPM como trampa, pero sólo si está seguro de que no ha sido modificada. Debería copiar la base de datos RPM en un disquete y mantenerla alejada siempre. La distribución Debian probablemente tiene algo similar. Especialmente los ficheros /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm probablemente no cabrán en un sólo disco. Ahora cuando su sistema haya sido comprometido puede usar el comando: <tscreen><verb> root# rpm -Va </verb></tscreen> para verificar cara fichero del sistema. Vea la página de manual de RPM, ya que allí hay algunas otras opciones que se pueden incluir para dar más información. Esto significa que cada vez que se añade un nuevo RPM al sistema, la base de datos RPM tendrá que ser rearchivada. Tendrá que decidir entre ventajas e inconvenientes.  <sect1>Mantener la Pista de Sus Datos de Contabilidad del Sistema Es muy importante que la información que llega con syslog no haya sido comprometida. Hacer que los ficheros de /var/log tengan lectura y escritura por un número limitado de usuarios es un buen comienzo. Esté seguro de tener un ojo en lo que se escribe allí, especialmente con la utilidad 'auth'. Muchos fallos de login, por ejemplo, pueden indicar un intento de romper la seguridad del sistema. Lo que debe buscar en los registros dependerá de la distribución. En sistemas Linux que verifican el Estándar de Sistema de Ficheros Linux ( "Linux Filesystem Standard"), como Red Hat, tendrá que mirar en /var/log and y comprobar messages, mail.log, y otros. Puede encontrar donde su distribución registra la información mirando en su /etc/syslog.conf file. Este es el fichero que le dice a syslogd (el demonio de registros del sistema) donde registrar los distintos mensajes. Podría también querer configurar el guión (script) de rotación de sus logs para una mayor duración para que le dé tiempo a examinarlos. Dele un vistazo a paquete logrotate de las distribuciones recientes de Red Hat. Otras distribuciones probablemente tengan un proceso similar. Si su ficheros de registro han sido falsificados, determine cuando se inició y qué tipo de cosas parece que se han falsificado. ¿Hay largos periodos en los que no aparecen registros? Comprobar las cintas de copias de salvaguardia (si las tiene) para ver ficheros no falsificados puede ser una buena idea. Los ficheros de de registro normalmente se modifican por el intruso para cubrir sus pistas, pero se deberían comprobar para buscar sucesos extraños. Puede darse cuenta del intruso que está intentando obtener acceso o explotar un programa para conseguir acceso de root. Debe ver los registros antes de que el intruso tenga tiempo de modificarlos. Debería también estar seguro de separar la facilidad 'auth' de otros datos de registros, incluyendo intentos de cambios de usuario usando 'su', intentos de conexión y otra información de contabilidad. Si es posible, configure syslog para enviar una copia de los datos más importantes a un sistema seguro. Esto nos prevendrá de que un intruso cubra sus huellas borrando sus intentos login/su/ftp/etc. Vea la página de manual de syslog.conf y busque la opción `@'. Finalmente los ficheros de registro son mucho menos útiles cuando nadie los lee. Tome algún tiempo de vez en cuando para mirar sus registros, y vea como son en un día normal. Esto, le será útil para distinguir cuando pasa algo inusual.  <sect1> Aplicar Todas las Nuevas Actualizaciones del Sistema La mayoría de los usuarios de Linux instalan desde un CDROM. Debido a la rapidez con que corrigen los problemas de seguridad, siempre están apareciendo nuevas versiones de los programas. Antes de que conecte su máquina a la red es una buena idea verificar con el sitio ftp se su distribución (ftp.redhat.com por ejemplo) y conseguir todas los paquetes de actualizaciones desde que salió su CDROM de distribución. Muchas veces estos paquetes contienen importantes correcciones de seguridad, por lo que es conveniente tenerlos instalados.  <sect> ¿Qué hacer Durante y Después de una Ruptura? ¿Ha seguido algunos de las advertencias que se indicaban aquí (o en otro sitio) y ha detectado una ruptura? Lo primero es mantener la calma. Las acciones apresuradas pueden causar más daño que el que podría causar un atacante.  <sect1> Compromiso de seguridad en Curso. Localizado un compromiso de seguridad en curso puede ser una tarea tensa. Según reaccione puede tener graves consecuencias. Si el compromiso que está viendo es físico, ha pillado a alguien que ha entrado en su oficina o laboratorio, tendría que notificarlo a las autoridades. En un laboratorio puede estar intentado abrir la caja o reiniciar una máquina. Dependiendo de su autoridad y procedimientos, le podría decir que parara o llamar a un servicio de seguridad. Si ha detectado a un usuario local intentando comprometer la seguridad lo primero que tiene que hacer es confirmar que realmente es quien parece ser. Compruebe el sitio si tiene registros de login. ¿Está en el sitio habitual? Entonces use un medio no electrónico para ponerse en contacto. Por ejemplo, llámelo por teléfono o vaya andando por el edificio/casa y hable con ellos/ellas. Si reconocen que están conectados, puede preguntarles la explicación qué están haciendo o decirles que dejen de hacerlo. Si no están conectados y no tienen ni idea de lo que les está hablando, este incidente requiere una mayor investigación. Busque en el incidente, y consiga un montón de información antes de hacer acusaciones. Si ha detectado un compromiso de red, lo primero que tiene que hacer (si puede) es desconectar la red. Si están conectados mediante módem, desconecte el cable del módem. Si están conectados vía ethernet, desconecte el cable de ethernet. Esto prevendrá que hagan más daño, y ellos además lo verán más como un problema de red más que una detección. Si no puede desconectar la red (si tiene un sitio ocupado, o no tiene control físico de la máquina), el mejor paso siguiente es usar algo como tcp_wrappers o ipfwadm para denegar accesos del sitio de donde se hace la intrusión. Si no puede denegar a toda la gente del mismo sitio del intruso, cierre la cuenta del usuario. Observe que cerrar una cuenta no es una cosa simple. Tiene que tener en cuenta los ficheros .rhosts, el acceso FTP y otras puertas traseras. Tras haber hecho lo anterior (desconectar la red, denegar el acceso de sitio y/o desactiva la cuenta), necesita matar todos sus procesos de usuario y desconectarlos. Debería monitorizar su sitio bien durante los próximos minutos, ya queel atacante intentará regresar. Quizás usando un cuenta diferente y/o de diferente dirección de red.  <sect1> El Compromiso de Seguridad ya ha Ocurrido Bueno, bien ha detectado un compromiso que ya a ocurrido o bien lo ha detectado y ha echado (espero) al atacante fuera de su sistema. ¿Y ahora qué?  <sect2> Cerrar el Agujero Si ppuede determinar qué medios usó el atacante para entrar en su sistema, debería intentar cerrar el agujero. Por ejemplo, quizás ha visto varias entradas FTP justo antes de que el usuario entrara. Desactive el servicio FTP y compruebe y vea si hay una versión actualizada o alguna de la lista conocida de correcciones. Verifique todos su ficheros de registro y haga una visita a sus páginas de listas de seguridad y vea allí su hay algún nuevo exploit común que pueda corregir. Puede encontrar las correcciones de seguridad de Caldera aquí <htmlurl url="http://www.caldera.com/tech-ref/security/" name="http://www.caldera.com/tech-ref/security/">. Red Hat no tiene separados sus correcciones de seguridad de errores, pero las erratas de sus distribuciones están disponibles en <htmlurl url="http://www.redhat.com/errata" name="http://www.redhat.com/errata"> Es muy probable que alguno delos vendedores haya editado una actualización de seguridad, que la mayoría de los otros Linux también harán. Si no elimina el atacante, probablemente volverá. No a su máquina, sino a cualquiera otra de la red. Si ejecutaban algún sniffer, tiene buenos recursos para tener acceso a las máquinas locales.  <sect2> Valoración del Daño Lo siguiente que tiene que hacer es evaluar el daño. ¿Qué se ha comprometido? Si ejecuta un Verificador de Integridad como Tripwire podría decírselo. Si no, tendrá que mirar todos sus datos importantes. Como los sistemas Linux se están volviendo más y más fáciles de instalar, podría considerar guardar sus ficheros de configuración y limpiar los discos y reinstalar, y después restaurar sus ficheros de usuario de las copias de seguridad y los ficheros de configuración. Esto asegura que tiene un sistema limpio. Si tiene ficheros de copias de seguridad del sistema comprometido, sea especialmente cuidadoso con los binarios que restaura, ya que pueden ser caballos de troya situados allí por el intruso.  <sect2> Backups, Backups, Backups! Tener copias regulares de seguridad es una suerte para asuntos de seguridad. Si su sistema está comprometido, puede restaurar los datos que necesite de estas copias. Desde luego, algunos datos tienen valor para los atacantes y no sólo los destruirán , los robarán y tendrán sus propias copias, pero al menos tiene los datos. Debería verificar varias copias de salvaguardia anteriores antes de restaurar un fichero que haya sido falsificado. El intruso podría haber comprometido sus ficheros hace tiempo y podría haber hecho muchas copias de seguridad del fichero falsificado. Desde luego, también tiene que tener seguras sus copias de salvaguardia. Tenga cuidado de guardarlas en lugar seguro. Saber quien tiene acceso a ellos. (Si un atacante puede obtener las copias de seguridad, puede obtener acceso a todos los datos sin que ni siquiera lo sepa).  <sect2> Siguiendo la Pista del Intruso. Ha expulsado al intruso y ha recuperado su sistema, pero no todo está hecho. Mientras sea improbable que la mayoría de los intrusos sean capturados, debería informar del ataque. Debería informar del ataque al contacto con el admin en el sitio de donde el atacante atacó a su sistema. Puede buscar este contacto con whois o la base de datos del internic. Podría enviarles un mensaje de correo con todos los registros aplicables y fechas y horas. Si tiene algo más distintivo sobre su intruso, podría mencionarlo también. Tras enviar el correo (si le parece bien) podría llamar por teléfono. Si el admin localiza a su atacante, podría hablar con él. Los buenos hackers con frecuencia usan muchos sistemas intermedios. Algunos (o muchos) puede que ni sepan que han sido comprometidos. Intentar seguir la pista de un cracker hasta su origen puede ser difícil. Siendo educado con los admins le puede llevar un largo recorrido obtener ayuda de ellos. Debería notificarlo también a alguna organización de seguridad de la que foram parte (CERT o similar).  <sect> Security Sources Hay un montón de buenos sitios para seguridad de Unix en general y seguridad de Linux en particular. Es muy importante suscribirse a una o más listas de correo de seguridad y estar actualizado sobre las correcciones de seguridad. La mayoría de las listas tienen muy bajo volumen y son muy informativas.  <sect1> Sitios FTP CERT es el Computer Emergency Response Team. Con frecuencia envían alertas sobre ataques actuales y correciones. <htmlurl url="ftp://ftp.cert.org" name="cert.org"> Replay tiene archivos de muchos programs de seguridad. Como están fuera de EE.UU. no están sujetos a la obediencia a las restricciones de cifrado <htmlurl url="ftp://ftp.replay.com" name="replay.com"> Matt Blaze es el autor de CFS y un gran defensor de la seguridad. <htmlurl url="ftp://ftp.research.att.com/pub/mab" name="Matt Blaze's stuff"> tue.nl es un gran sitio ftp de seguridad en Holanda. <htmlurl url="ftp://ftp.win.tue.nl/pub/security/" name="ftp.win.tue.nl">  <sect1> Sitios Web The Hacker FAQ es una FAQ sobre hackers: <htmlurl url="http://www.solon.com/~seebs/faqs/hacker.html" name="The Hacker FAQ"> En castellano http://usuarios.santafe.com.ar/~cballard/pf/hacker-howto.es.html El archivo COAST tiene un gran número de programas de seguridad Unix e información: <htmlurl url="http://www.cs.purdue.edu/coast/" name="COAST"> Rootshell.com es un gran sitio para ver qué exploits están siendo utilizados actualmente por los crackers: <htmlurl url="http://www.rootshell.com/" name="rootshell.com exploits"> BUGTRAQ pone avisos de temas de seguridad: <htmlurl url="http://www.netspace.org/lsv-archive/bugtraq.html" name="BUGTRAQ archives"> CERT, el Computer Emergency Response Team, pone avisos sobre ataques comunes a plataformas Unix: <htmlurl url="http://www.cert.org/" name="CERT home"> Dan Farmer es el autor de SATAN y otras muchas herramientas, su sitio tiene información interesante junto con herramientas de seguridad: <htmlurl url="http://www.trouble.org" name="Dan Farmers trouble.org"> La Linux security WWW es un buen sitio para consguir información de seguridad para Linux: <htmlurl url="http://www.aoy.com/Linux/Security/" name="Linux Security WWW"> Reptile tiene montones de buena información sobre seguridad en Linux en su sitio: <htmlurl url="http://207.237.120.45/linux/" name="Reptiles Linux Security Page"> Infilsec tiene un motor de vulnerabilidad que puede decirle que vulnerabilidades afectan a una plataforma específica: <htmlurl url="http://www.infilsec.com/vulnerabilities/" name="Infilsec vunerability engine"> CIAC envía construcciones periódicas de seguridad sobre exploits comunes: <htmlurl url="http://ciac.llnl.gov/cgi-bin/index/bulletins" name="CIAC bulitins"> Un buen buen punto de inicio para Linux Pluggable Authentication Mdules (PAM) se puede encontar en <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/" name="http://www.kernel.org/pub/linux/libs/pam/">.  <sect1> Listas de correo Bugtraq: Para suscribirse a bugtraq, envíe un mail a listserv@netspace.org que contenga en el cuerpo del mensaje subscribe bugtraq. (ver el enlace anterior para los archivos). CIAC: Envíe un e-mail a: majordomo@tholia.llnl.gov En el cuerpo(no en el subject) del mensaje ponga: subscribe ciac-bulletin  <sect1> Libros - Material Impreso Listo Hay muy buenos libros de seguridad. Esta sección lista unos pocos de ellos. Además, los libros específicos de seguridad, la seguridad está cubierta en gran número de libros sobre administración. Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4  <sect> Glosario <itemize> <item><bf>Host:</bf> Un sistema (ordenador, computador) agregado a una red. <item><bf>Cortafuegos (Firewall):</bf> Un componente o conjunto de componentes que restringe el acceso entre un red protegida e internet u otro conjunto de redes. <item><bf>Host Bastiont:</bf> Un host que tiene que ser altamente seguro porque es vulnerable a ataques, normalmente porque está expuesto a internet y es un punto de contacto principal de usuarios de redes internas. Obtiene su nombre de los proyectos altamente fortificados de los muros exteriores de los castillos medievales. Los bastiones vigilan áreas críticas de defensa, normalmente con fuertes muros, habitáculos para tropas extras, y los tubos ocasionales de aceite hirviente para disuadir a los atacantes. <item><bf>Host Dual-homed:</bf> Un host de propósito general que tiene al menos dos interfaces de red. <item><bf>Paquete (Packet):</bf> La unidad fundamental de comunicación en internet. <item><bf>Filtrado de Paquetes (Packet Filtering):</bf> La acción que toma un dispositivo para controlar selectivamente el flujo de datos desde y hacia la red. Los filtros de paquetes permiten o bloquean paquetes, normalmente mientras los enruta de una red a otra (con más frecuencia de internet a un red interna y viceversa). Para llevar a cabo el filtrado de paquetes tiene que activar un conjunto de reglas que especifican qué tipo de paquetes (los que vienen a van a una determinada dirección IP o puerto) se permiten que tipos se bloquean. <item><bf>Red de Perímetro (Perimeter network):</bf> Una red añadida entre una red protegida y la red externa, para proporcionar una seguridad añadida. A una red de perímetro también se la denomina a veces una DMZ. <item><bf>Servidor Proxy (Proxy server):</bf> Un programa que trata con servidores externos en nombre de los clientes internos. Los clientes proxy hablan con el servidor proxy, que rehace las peticiones de los clientes hacia un servidor real y devuelve sus respuestas a los clientes. <item><bf>Denegación de Servicio (Denial of Service):</bf> Un ataque de denegación de servicio es cuando un atacante consume los recursos de un equipo por cosas que no estaba intentando hacer, así impidiendo el uso normal de los recursos de su red para propósitos legítimos. <item><bf>Desbordamiento del Buffer (Buffer Overflow) :</bf> El estilo de codificación común nunca asigna buffer suficientemente grandes y no comprueba los desbordamientos. Cuando esos buffer se desbordan, el programa en ejecución (demonio o programa set-uid) se puede trucar para hacer algunas cosas. Generalmente esto funciona sobreescribiendo la dirección de retorno de una función en la pila para apuntar a otra ubicación. <item><bf>Falsificación IP (IP Spoofing):</bf> IP-Spoofing es una técnica compleja de ataque que se hace de varios componentes. Es un exploit de seguridad que funciona engañando a equipos con una relación de confianza por alguien que no es quien dice ser. Hay un trabajo extenso escrito por daemon9, route e infinity en el Volume Seven, Issue Fourty-Eight de Phrack Magazine. <item><bf>Autenticidad (Authentication):</bf> La propiedad de saber que el dato recibido es el mismo que el dato que fue enviado y que el remitente que dice es el remitente de hecho. <item><bf>No repudiación (Non-repudiation):</bf> La propiedad del receptor de ser capaz de probar que el remitente de algún dato hizo de hecho el envío del dato incluso aunque el remitente pueda más tarde querer denegar haber enviado ese dato. </itemize>  <sect>Preguntas de Uso Frecuente (PUF) Frequently Asked Questions (FAQ) <enum> <item> ¿Es más seguro compilar el soporte del controlador directamente en el núcleo en lugar de crear un módulo? Respuesta: Algunos piensan que es mejor desactivar la posibilidad de cargar controladores de dispositivos usando módulos, porque un intruso podría cargar un módulo troyano o él mismo cargar un módulo que podría afectar a la seguridad del sistema. Sin embargo, para cargar módulos hay que ser root. Los ficheros de objetos módulos sólo tienen escritura por el root. Esto significa que el intruso necesitaría tener acceso de root para insertar un módulo. Si el intruso obtiene acceso de root, hay cosas más serias de las que preocuparse que si ha cargado un módulo. Los módulos son soporte para carga dinámica para un dispositivo particular que no se usa con frecuencia. En máquinas servidoras, o cortafuegos por ejemplo, esto nos es probable que suceda. Por esta razón, tendría más sentido compilar el soporte directamente en el núcleo para máquinas que actúan como servidores. Los módulos también son más lentos que el soporte compilado directamente en el núcleo. <item> Los Login como root desde una máquina remota siempre fallan. Respuesta: Vea la sección sobre seguridad de root. Esto está hecho intencionalmente para prevenir que usuarios remotos intenten conectar mediante telnet a su máquina como root, que sería una seria vulnerabilidad. No olvide, los intrusos potenciales tienen el tiempo de su parte y pueden usar programas automatizados para encontar su clave. <item> ¿Como activo shadow passwords en mi Linux Red Hat 4.2 o 5.0 ? Respusta: Shadow password es un mecanismo para almacenar sus claves en otro fichero distinto al habitual /etc/passwd. Esto tiene varias ventajas. La primera es que el fichero donde se guardan, /etc/shadow, sólo lo puede leer el root mientras que /etc/passwd tiene que permanecer con permiso de lectura para todos. Otra ventaja es que como administrador, puede activar o desactivar cuentas sin que nadie sepa el estado de los otros usuarios. El fichero /etc/passwd se usa entonces para almacenar usuario y nombre de grupos, usados por programas como `/bin/ls' para aplicar el ID al nombre de usuario adecuado en un listado de un directorio. El fichero /etc/shadow por tanto sólo contiene el nombre de usuario u su clave, y quizás información administrativa, como cuando expira la cuenta, etc. Para activar shadow passwords, ejecute 'pwconv' como root, y su /etc/shadow se creará, y será usado por las aplicaciones. Como usa RH 4.2 o superior, los módulos PAM se adaptarán automáticamente a la modificación de cambiar el uso de /etc/passwd normal a shadow passwords sin otro cambio. Como está interesado en asegurar sus claves, quizás estaría interesado en generar claves buenas para empezar. Para esto puede usar el módulo `pam_cracklib' que es parte de PAM. Este módulo ejecuta su clave con las librerías Crack para ayudarle a decidir si es demasiado fácil de adivinar por programas de ruptura de claves. <item> ¿Como activo la extensiones Apache SSL? Respuesta 1.Consiga SSLeay 0.8.0 o posterior de ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL 2.Constrúyalo, verifique e instálelo 3.Consiga las fuentes de Apache 1.2.5 4.Consiga las extensiones Apache SSLeay de <url url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz" name="here"> 5.Desempaquételo en el directorio fuente de apache-1.2.5 y parchee Apache según el README. 6.Configure y constrúyalot. También puede intentar <htmlurl url="http://www.replay.com" name="Replay Associates"> que tiene muchos paquetes preconstruidos y está fuera de EE.UU. <item> ¿Cómo puedo manipular las cuentas de usuario, y seguir manteniendo la seguridad? Respuesta: La distribución Red Hat, especialmente RH5.0, contiene un gran número de herramientas para cambiar las propiedades de las cuentas de los usarios. <itemize><item> Los programas pwconv y unpwconv se pueden usar para convertir y en y restaurar las shadow passwd. <item>Los programas pwck grpck se pueden usar para verificar la correcta organización de lso ficheros passwd y group <item> El programa useradd, usermod, y userdel se pueden usar para añadir, modificar y borrar cuentas de usuario. Los programas groupadd, groupmod, y groupdel hacen lo mismo para grupos. <item>Las claves de grupos se pueden crear con gpasswd. </itemize> Todos estos programas funcionan con shadow passwd, esto es, si activa shadow, usaran /etc/shadow para la inforamción de las claves, y si no, no. Vea las respectivas páginas del manual para una mayor información. <item> ¿Cómo puedo proteger con clave documetos HTML específicos usando Apache? Apuesto que no conoce <htmlurl url="http://www.apacheweek.com" name="http://www.apacheweek.org"> ¿Verdad? Puede encontar información sobre Autenticidad de Usuarios en <htmlurl url="http://www.apacheweek.com/features/userauth" name="http://www.apacheweek.com/features/userauth"> también como otros trucos de servidores web de <htmlurl url="http://www.apache.org/docs/misc/security_tips.html" name="http://www.apache.org/docs/misc/security_tips.html"> </enum>  <sect> Conclusión Suscribiéndose a las listas de correo de alertas de seguridad, y estando al día, puede avanzar en la seguridad de su máquina. Si presta atención a sus ficheros de registro y ejecuta regularmente algo como tripwire puede incluso conseguir más. Un nivel razonable de seguridad del equipo no es difícil de mantener en sistema doméstico. En máquinas de negocios se requieren más esfuerzos, pero Linux puede ser una plataforma segura. Debido a la naturaleza del desarrollo de Linux, las correcciones de seguridad llegan mucho más rápido que en los sistema operativos comerciales, haciendo de Linux una plataforma ideal cuando se requiere seguridad.  <sect> Agradecimientos La información recogida aquí es recopilada de muchas fuentes. Gracias a quienes indico a continuación, que directa o indirectamente han contribuido: <tscreen><verb> Rob Riggs <rob@DevilsThumb.com> S. Coffin <scoffin@netcom.com> Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu> Roelof Osinga <roelof@eboa.com> Kyle Hasselbacher <kyle@carefree.quux.soltec.net> "David S. Jackson" <dsj@dsj.net> "Todd G. Ruskell" <ruskell@boulder.nist.gov> Rogier Wolff <R.E.Wolff@BitWizard.nl> </verb></tscreen>  </article>