Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - KarlosVid(ÊÇ)

#641
Ingenioso ataque explota kernel de Linux completamente actualizado


Una falla de 'puntero NULO' plaga incluso las versiones super max

Un ataque recientemente publicado que explota nuevas versiones del kernel de Linux está recibiendo mucha atención porque funciona incluso con las mejoras de seguridad en funcionamiento y la falla es virtualmente imposible de detectar en revisiones de código fuente.

El código de explotación fue liberado el viernes por Brad Spengler de grsecurity, un desarrollador de aplicaciones que mejoran las seguridad del SO de fuente abierto. Si bien está dirigido a versiones de Linux que aun deben ser adoptadas por la mayoría de los vendedores, el fallo ha capturado la atención de los investigadores de seguridad, quienes dice que expone una debilidad pasada por alto.

Los desarrolladores de Linux "intentaron protegerse de eso y lo que muestra esta explotación es que incluso con todas las protecciones puestas al super máximo, aún es posible para un atacante arreglárselas para hallar caminos para rodear al sistema," dijo Bas Alberts, investidador experto de Immunity. "El punto interesante aqui es la cosa concreta que lo hace explotable, la clase completa de vulnerabilidades, la cual es algo muy serio."

La vulnerabilidad está localizada en varias partes de Linux, incluyendo una que implementa las funciones conocidas como net/tun. Aunque el código verifica correctamente para asegurarse que la variable tun no apunte a NULL, el compilador elimina las lineas responsables para esa inspección durante las rutinas de optimización. El resultado: Cuando la variable apunta a cero, el kernel intenta acceder a partes prohibidas de la memoria, llevando a comprometer al equipo que está corriendo el SO.

La falla de "des-referenciamiento de puntero NULL(nulo)" ha sido confirmada en versiones 2.6.30 y 2.6.30.1 del kernel Linux, el cual dice Spengler ha sido incorporado en la edición de un sólo proveedor: la version 5 de Red Hat Enterprise Linux que es usado en ambientes de prueba. La explotación funciona sólo cuando las extensiones de seguridad conocidas como SELinux, o Seguridad Mejorada Linux, están habilitadas. En cambio, también funciona cuando cuando el programa de audio conocido como PuseAudio está instalado.

Un escenario de explotación muy probablemente involucraría el ataque usando para escalar los privilegios de usuario, combinado con la explotación de otro componente - digamos, una aplicación PHP. Por sí mismo, la explotación de Spengler no funciona remotamente.

Con todos esos obstáculos por sortear, la explotación necesita un buen esfuerzo para ser exitosa. Sin embargo, a Spengler le tomó menos de cuatro horas escribir una explotación completamente armada que funciona en versiones de 32 y 64 bits de Linux, incluyendo la versión ofrecida por Red Hat. Le dijo a The Register que publicó la explotación después de dejar en claro que Linus Torval y otros desarrolladores responsables del kernel de Linux no consideraron a la falla como un riesgo de seguridad.

"En el momento que escribí la explotación, había por allí un parche, pero no parecía que fuera a formar parte de las versiones estables," dijo. "Fue más que nada un oops trivial en lugar de algo que le diera a uno la ejecución arbitraria de código en el kernel."

Los comentarios que acompañan la explotación de Spengler continuan hasta el detalle de declaraciones de Torvalds y otros desarrolladores que dijeron que hicieron en grupos de discución por correo sobre la falla.

"No me parece para nada un problema del kernel," es citado como mencionado por Torval en un mensaje. "Él está corriendo un programa de setuid que permite al usuario especificar sus propios módulos. ¿Y después se sorprenden uds, que consiga hacerse root local?"

En ese frente, al menos un investigador de seguridad estuvo de acuerdo con el equipo de Linux.

"Setuid es un agujero de seguridad crónico bien conocido," escribió en un correo Rob Graham, CEO de Errata Security. "Torval está en lo correcto, no es un problema de kernel, sino una 'falla' de diseño que es heredada de Unix. No hay una solución sencilla al problema, por lo cual, va a está con nosotros por varios años."

El punto máas grande, dice Spengler, es que los desarrolladores de Linux están poniendo a los usuarios en riesgo al dejar de revelar claramente cuando son descubiertas vulnerabilidades de seguridad.

"¿Porqué es que cuandoquiera que hay una vulnerabilidad explotable de Linux, se la describe como una denegación de servicio?" dijo. "Eso hace que los proveedores piensen que la seguridad está mejor de lo que verdaderamente es."

Dondequiera que la falla suceda, el daño potencial es muy real.

"No va a prender el mundo en llamas, pero es una falla muy sutil y una explotación sólida," dijo Ed Skoudis, fundador y consultor principal de seguridad de InGuardians. "La verdadera historia aquí es que sutil que es, y que el compilador por sí mismo la introdujo durante la optimización del código."

Hasta aquí, Torvald y compañía aun tienen que responder por la divulgación. Nos aseguraremos de actualizar esta historia si lo hacen.

Autor: Dan Gooding
Fuente: The Register UK
#642
INDICE GENERAL
1.- VIDEOS
   1.1.- Clases de Ajedrez - Buho21.com (23 clases)
   1.2.- Clases de Ajedrez - Gerardo Hernandez - (13 clases)
           1.2.1.- Clase (1-4)
           1.2.2.- Clase (5-8)
           1.2.3.- Clase (9-12)
   1.3.- Redes - Ajedrez (7 capítulos)
           1.3.1.- Capítulo (1-3)
           1.3.2.- Capítulo (4-7)
   1.4.- La Pasion del Ajedrez (25 videos)
           1.4.1.- Video 01
           1.4.2.- Video 02
           1.4.3.- Video 03
           1.4.4.- Video 04
           1.4.5.- Video 05
           1.4.6.- Video 06
           1.4.7.- Video 07
           1.4.8.- Video 08
           1.4.9.- Video 09
           1.4.10.- Video 10
           1.4.11.- Video 11
           1.4.12.- Video 12
           1.4.13.- Video 13
           1.4.14.- Video 14
           1.4.15.- Video 15
           1.4.16.- Video 16
           1.4.17.- Video 17
           1.4.18.- Video 18
           1.4.19.- Video 19
           1.4.20.- Video 20
           1.4.21.- Video 21
           1.4.22.- Video 22
           1.4.23.- Video 23
           1.4.24.- Video 24
           1.4.25.- Video 25
   1.5.- Cuarto milenio-Misterios del ajedrez
   1.6.- El Mundo del Ajedrez- Mundial México 2007
   1.7.- Aperturas de ajedrez
           1.7.1.- Apertura Ruy Lopez - Nivel básico
           1.7.2.- Variadas - aperturas
                    1.7.2.1.- Derechos de autor en las partidas de ajedrez
                    1.7.2.2.- Sacrificios en la Apertura Escocesa
                    1.7.2.3.- La partida del siglo Byrne,Donald - Fischer,Robert James
                    1.7.2.4.- Gambitro de Centro
                    1.7.2.5.- Apertura Española Ruy Lopez Defensa Steinitz Antigua C62
                    1.7.2.6.- Apertura Española Alexander Alekhine vs Forrester 1923
                    1.7.2.7.- Colección EDAMI "Libros de Aperturas de Ajedrez"
                    1.7.2.8.- C.D.E. Ajedrez Añover (Concepto de Aperturas)
                    1.7.2.9.- J Polgar Madmedyarov Apertura Española
                    1.7.2.10.- Celada Apertura Catalana
                    1.7.2.11.- Trampas en la Apertura
                    1.7.2.12.- Trampa - Gambito de Rey #1
   1.8.- Jaque Mate
           1.8.1.- Jaque mate Pastor
           1.8.2.- Jaque mate Loco
           1.8.3.- Jaque mate del Guardiamarina
           1.8.4.- Jaque mate El mate fantasma
           1.8.5.- Jaque mate En 1 jugada
           1.8.6.- Rey y ...
                    1.8.6.1.- Rey y 1 Torre Vs Rey 2
                    1.8.6.2.- Rey y 2 alfiles  Vs Rey
                    1.8.6.3.- Rey, 1 Alfil y 1 Caballo  Vs Rey

   1.9.- Otros
           1.9.1.- Match Spassky-Fischer 1972 (6 capítulos)
                     1.9.1.1.- Capítulo (1-3)
                     1.9.1.2.- Capítulo (4-6)
            1.9.2.- Viswanathan Anand, Campeón mundial de Ajedrez (2010)
            1.9.3.- El Gran Maestro de Ajedrez más joven del mundo!!
            1.9.4.- Documental del Ajedrez (6 Videos)

2.- TUTORIALES
   2.1.- Lista de Direcciones Web
   2.2.- Detección del talento ajedrecista
   2.3.- Aspectos ligados a la personalidad del ajedrecista
   2.4.- Cursos de Ajedrez
   2.5.- Libros de Ajedrez
          2.5.1.- El Camino Hacia La Maestría, Walter Meiden y Max Euwe
   2.6.- Biblioteca De Ajedrez (25 Volumenes)
   2.7.- Partidas de Ajedrez
   2.8.- INICIOS DEL AJEDREZ
           2.8.1.- Orígenes del Ajedrez
           2.8.2.- Historia del Ajedrez
   2.9.- El Ajedrez

3.- JUEGOS
   3.1.- Chessmaster XI Grandmaster
   3.2.- Juegos Portables - (Ajedrez1 y J.C.R.M)
   3.3.- Chess Tool PGN
   3.4.- ajedrezzzzzz 11 = by Veren
   3.5.- Chessmaster (celular) = by La Muerte Blanca

4.- NOTICIAS
   4.1.- Torneos
   4.2.- Noticias ChessBase
   4.3.- Lista de Direcciones Web - (31 links).

5.- Sabias Qué...?
   5.1.- El ajedrez en la Edad Moderna
   5.2.- El ajedrez de Lewis
   5.3.- 11 Trucos de Ajedrez
   5.4.- Campeonatos del Mundo Ajedrez
           5.4.1.- Campeonato Mundial de Ajedrez 2010
   5.5.- Poema Ajedrez
   5.6.- Poesía Ajedrez
   5.7.- Mejores Ajedrecistas de la historia (Bobby Fischer y Gari Kaspárov).

6. IMÁGENES
   6.1.- Lista Imagen _ 1
   6.2.- Lista Imagen _ 2
   6.3.- Lista Imagen _ 3
   6.4.- Lista Imagen _ 4
   6.5.- Lista Imagen _ 5

7. BIBLIOGRAFÍAS DE LOS CAMPEONES MUNDIALES

* Wilhelm Steinitz (1866-1894) - Austria
* Emanuel Lasker (1894-1921) - Alemania
* José Raúl Capablanca (1921-1927) - Cuba
* Alexander Alekhine (1927-1935 ,1937-1946) Rusia
* Max Euwe (1935-1937) Holanda
* Mikhail Botvinnik (1948-1957, 1958-1960 y 1961-1963) Unión Soviética
* Vassily Smyslov (1957-1958) Unión Soviética
* Mikhail Tal (1960-1961) Unión Soviética
* Tigran Petrosian (1963-1969)  Unión Soviética
* Boris Spassky (1969-1972)  Unión Soviética
* Bobby Fischer (1972-1975) Estados Unidos
* Antoly Karpov (1975-1985)  Unión Soviética
* Garri Kasparov (1985-2000)  Unión Soviética
* Vladimir Kramnik (2000-2007)  Unión Soviética
* Viswanathan Anand (2008-2010) La India

8.- Comentarios: Orden de post, en el tema.  ;-)
   * h0oke, Axus, yami-chan, h0oke, kamsky, Veren, Martin-Ph03n1X, La Muertع Blancα, Fischer987, Fischer987,...

Posteen si tienes algún tema relacionado sobre el ajedrez.  De grano en grano se construye castillos. :D
Gracias a tod@s l@s participantes del tema.  ;)

Salu2
#643
Tengo 2 preguntas: ;D
¿Cuales son la diferencia entre un Moderador, Moderador Global y un Colaborador? :huh:
¿Cuáles son los permisos de cada uno?  :huh:

Saludos... ;)
#644
El trabajo de BlackSr se ve mas original. Me gustaria participar, soy bueno en diseño gráfico ::). Andale, dime cuales son los requisitos y a que correo o dirección se emvia el trabajo.  :laugh: Muy buena la idea de la encuesta wallpaper.  Creo que es Azielito, es el encargado  :)

Saludos... :xD
#645
Guía de Seguridad del Administrador de Linux - GSAL
;-)

Burocracia

  * Licencia y garantía
  * Prefacio
  * Acerca del Autor
  * Acerca del Traductor
  * Comentarios a la traducción
  * Contribuciones
  * Colaboradores
  * Qué es y qué no es esta guía
  * Modificaciones

Empezando

  * Cómo determinar qué asegurar y cómo asegurarlo
  * Instalación segura de Linux
  * Conceptos generales, servidor versus estaciones de trabajo, etc.

El núcleo del sistema

  * Ficheros del sistema
  * Seguridad de Ficheros / Sistema de Ficheros
  * PAM

Seguridad física / consola
  * Seguridad Física / de Arranque

Contraseñas

  * Seguridad de contraseñas
  * Almacenamiento de contraseñas

Seguridad básica de red

  * Seguridad básica de servicios de red
  * Ficheros básicos de configuración de red

Seguridad TCP-IP

  * TCP-IP y seguridad de red
  * Seguridad PPP
  * Seguridad IP (IPSec)
  * Cifrado de datos / servicios
  * Rutado

Cortafuegos / Proxies

  * Software de Proxy
  * Cortafuegos

Servicios de Red

  * Telnet
  * SSH
  * FTP
  * HTTP / HTTPS
  * SMTP
  * POP
  * IMAPD
  * DNS
  * NNTP
  * DHCP
  * rsh, rexec, rcp
  * NFS
  * TFTP
  * BOOTP
  * SNMP
  * FINGER
  * IDENTD
  * NTP
  * CVS
  * rsync
  * lpd
  * SMB (SAMBA)
  * LDAP
  * Sistema X Window
  * Conectividad SNA
  * Software de Autoridad de Certificación para Linux

Descargar: http://es.tldp.org/Manuales-LuCAS/GSAL/gsal-19991128.pdf
#646
Apoyo al ajredrez  :laugh:  http://foro.elhacker.net/foro_libre/torneo_ajedrez-t261053.30.html
Seria divertido que exista uno. Cuentan con mi apoyo.



#647
Gracias BadStupidMonkey , por la respuesta.  ;-)
#648
Una pregunta, este codigo que encontre, no se si es verdad que funcione o que codigo que recomienda para sacar el numero IP del cliente que nos visita.  :huh:



Una vez hemos configurado el proxy en nuestro navegador, se puede conocer si estas cabeceras están siendo utilizadas accediendo a una página web del tipo "Cual es mi IP", que nos mostrará si utilizamos proxy o no y las direcciones IP que es capaz de detectar. Otra opción es hacer nuestro propio script donde se muestren las cabeceras enviadas con algo tan simple como:

    <?php
    
foreach($_SERVER as $h=>$v)
    if(
ereg('HTTP_(.+)',$h,$hp))
    echo 
"<li>$h = $v</li>\n";
    
header('Content-type: text/html');
    
?>


#650
¿Qué Quiere Proteger?

Normalmente querrá garantizar que el sistema permanece en funcionamiento de forma adecuada. Querrá garantizar que nadie pueda obtener o modificar una información a la que no tiene derecho legítimo. Y tambien querrá garantizar unas comunicaciones seguras. Una buena planificación ayuda bastante a conseguir los niveles de seguridad que pretendemos. Antes de intentar asegurar su sistema debería determinar contra qué nivel de amenaza quiere protegerse, qué riesgo acepta o no y, como resultado, cómo de vulnerable es su sistema. Debería analizar su sistema para saber qué está protegiendo, por qué lo está protegiendo, qué valor tiene y quiénes tienen responsabilidad sobre sus datos y otros elementos.

    * 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 también que alguien que obtenga acceso a su cuenta, o su sistema, también puede hacerse pasar por Vd.

      Además, bata tener una sola cuenta insegura en su sistema para comprometer 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.
    * La amenaza proviene de alguien que tiene motivos para obtener acceso sin autorización a su red o equipo. Debe decidir en quién confía para dotar de acceso a su sistema y qué 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.
          o

            El Curioso - Este tipo de intruso está interesado básicamente en qué tipo de sistema y datos posee.
          o

            El Malicioso - Este tipo de intruso pretenderá, bien hacerle caer su sistema, modificar su página web o cualquier otra cosa que le cueste tiempo y dinero recuperar.
          o

            El Intruso muy personalizado - Este tipo de intruso trata de usar su sistema para ganar popularidad o mala fama. Puede usar su sistema para promocionar sus habilidades.
          o La Competencia - 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.
    * La vulnerabilidad describe el nivel de protección de su equipo frente a otra red, y la posibilidad 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?

      La seguridad pretende que los sistemas informáticos que utiliza una entidad se mantengan en funcionamiento según los requisitos de la política establecida por la propia entidad. Cada entidad define una serie de servicios que pretende obtener de una red de ordenadores para prestarlos a unos usuarios legítimos. Básicamente los requisitos de seguridad se puede resumir en una serie de puntos ilustrativos:
          o Disponibilidad: consistente en mantener la información y los recursos de acuerdo con los requisitos de utilización que pretende la entidad que utiliza la red informática. La disponibilidad de la información pretende garantizar que no se limite el acceso autorizado a la información y el correcto funcionamiento de los recursos.
          o Integridad: la información que se almacena en los sistemas o que circula por las líneas de comunicación debe estar protegida contra la modificación no autorizada. Requiere que la información sólo pueda ser modificada por las entidades autorizadas.
          o Autenticidad: la información que se almacena o circula por una red debe permanecer protegida ante falsificaciones. La autenticidad requiere mecanismos de identificación correctos, asegurando que las comunicaciones se realizan entre entidades legítimas.
          o Confidencialidad: pretende evitar la difusión no autorizada de la información. Requiere que la información sea accesible únicamente por las entidades autorizadas.
          o No rechazo: establecer los mecanismos para que nadie pueda negar que ha realizado una determinada comunicación.

En particular, en Linux tendremos que proteger ciertos ficheros que contienen información sobre los usuarios (/etc/passwd, /etc/shadow), los ficheros de configuración del sistema (los contenidos en /etc), el acceso al sistema para que se realice según marca la política prevista y la correcta utilización de los recursos para evitar abusos (p.e. si un usuario tiene sólo una cuenta de correo, que no pueda abrir una shell en el sistema). A todo esto habrá que sumar la protección de los distintos servicios que presta.



Seguridad física

Las primeras medidas de seguridad que necesita tener en cuenta son las de seguridad física de sus sistemas. Hay que tomar en consideración quiénes tienen acceso físico a las máquinas y si realmente deberían acceder.

El nivel de seguridad física que necesita en su sistema depende de su situación concreta. Un usuario doméstico no necesita preocuparse demasiado por la protección física, salvo proteger su máquina de un niño o algo así. En una oficina puede ser diferente.

Linux proporciona los niveles exigibles de seguridad física para un sistema operativo:

    * Un arranque seguro
    * Posibilidad de bloquear las terminales
    * Por supuesto, las capacidades de un sistema multiusuario real.



Seguridad Local

Linux es un sistema operativo multiusuario real: puede haber varios usuarios trabajando simultáneamente con él, cada uno en su terminal. Esto obliga a tener en cuenta   medidas de seguridad adicionales. Además, según hablan las estadísticas, el mayor porcentaje de violaciones de un sistema son realizadas por usuarios locales. Pero no sólo hay que protegerse de las violaciones intencionadas, sino que el sistema debe protegernos de operaciones accidentales debidas a decuidos o ignorancia de los usuarios.

En este aspecto de la seguridad, Linux dispone de todas las características de los sistemas Unix: un control de acceso a los usuarios verificando una pareja de usuario y clave; cada fichero y directorio tienen sus propietario y permisos.

Por otro lado, la meta de la mayoría de los ataques es conseguir acceso como root, lo que garantiza un control total sobre el sistema. Primero se intentará conseguir acceso como usuario "normal" para posteriormente ir incrementando sus niveles de privilegio utilizando las posibles debilidades del sistema: programas con errores, configuraciones deficientes de los servicios o el descifrado de claves cifradas. Incluso se utilizan técnicas denominadas "ingeniería social", consistentes en convencer a ciertos usuarios para que suministren una información que debiera ser mantenida en secreto, como sus nombres de usuario y contraseñas.

En este apartado de seguridad local pretendemos dar unas ideas generales de los riesgos existentes, mecanismos para su solución y unas directrices de actuación que deberían convertirse en hábitos cotidianos.

Criptonomicón es un servicio ofrecido libremente desde el Instituto de Física Aplicada del CSIC. Para información sobre privacidad, por favor consulte la declaración de política sobre privacidad. Para sugerencias, comentarios o quejas, acuda al libro de visitas. Para contribuir al Criptonomicón, lea la página de contribuciones.



Seguridad del Sistema de Archivos

Una norma básica de seguridad radica en la asignación a cada usuario sólo de los permisos necesarios para poder cubrir las necesidades de su trabajo sin poner en riesgo el trabajo de los demás.

¿Como se puede poner en riesgo el correcto funcionamiento del sistema?

Podemos apuntar algunas ideas: violando la privacidad de la información, obteniendo unos privilegios que no le correspoden a un usuario, haciendo un uso desmedido de los recursos o modificando información legítima contenida en una máquina, como pueden ser el contenido de una página web o una base de datos.

¿Cómo podemos mantener un almacenamiento seguro?

La respuesta no puede ser concreta, pero sí que se pueden tomar ciertas medidas que garanticen un mínimo de seguridad y funcionalidad. Si Vd. va a administrar un sistema Linux para dar servicio a diversos usuarios, debería tener algunas nociones sobre sistemas de ficheros, que pasamos a explicar a El árbol de directorios

Para quienes no estén familiarizados con las características del sistema de almacenamiento de información en sistemas Unix, hay que indicar que se organizan en un único árbol de directorios. Cada soporte, disco, partición, disquete o CD tiene su propia organización lógica, un sistema de ficheros. Para poder usar uno de estos soportes tenemos que "montarlo" en un directorio existente. El contenido de la partición nos aparecerá como el contenido del directorio.

Un primer criterio para mantener un sistema seguro sería hacer una correcta distribución del espacio de almacenamiento. Esto limita el riesgo de que el deterioro de una partición afecte a todo el sistema. La pérdida se limitaría al contenido de esa partición. No hay unas normas generales aplicables; el uso al que vaya destinado el sistema y la experiencia son las bases de la decisión adecuada, aunque sí podemos dar algún consejo:

    * Si el sistema va a dar servicio a múltiples usuarios que requieren almacenamiento para sus datos privados, sería conveniente que el directorio /home tuviera su propia partición.
    * Si el equipo va a ser un servidor de correo, impresión, etc., el directorio /var o incluso /var/spool podrían tener su propia partición.
    * Algunos directorios son necesarios en la partición raíz. Contienen datos que son necesarios durante el proceso de arranque del sistema. Son /dev/, /etc, /bin, /sbin, /lib, /boot.
    * El directorio /usr/local contiene los programas compilados e instalados por el administrador. Resulta conveniente usar una partición propia para proteger estos programas personalizados de futuras actualizaciones del sistema. Este criterio también se puede aplicar al directorio /opt.



Seguridad Del Núcleo
Linux tiene la gran ventaja de tener disponible el código fuente del núcleo; en realidad Linux propiamente dicho es sólo el núcleo. Esto nos permite la posibilidad de crear núcleos a medida de nuestras necesidades. Y parte de nuestras necesidades será la mejora de la seguridad.

Para compilar el núcleo primero tendremos que configurar las opciones que nos interesen. Los fuentes del núcleo se guardan habitualmente en el directorio /usr/src/linux, y una vez situados en él, tendremos que ejecutar «make menuconfig» (o «make xconfig» si estamos en modo gráfico). Así nos aparecen todas las opciones de configuración. Dentro de ellas nos vamos a fijar en las que están relacionadas con la seguridad, viendo una breve explicación de lo que hacen y cómo se usan.

Como el núcleo controla las características de red de su sistema, es importante que el núcleo tenga las opciones que garanticen la seguridad y que el propio 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 las nuevas versiones del núcleo en The Linux Kernel Archives.

Una de las características más interesantes del núcleo Linux es la posibilidad de realizar enmascaramiento de direcciones. Con esta técnica podremos dar acceso a Internet a una red local con direcciones privadas de forma transparente, es decir, sin ningún tipo de modificación en la configuración de las aplicaciones clientes, a diferencia de los proxies clásicos. Consiste en que el sistema Linux que posee la conexión hacia el exterior recibe las peticiones de conexión desde los equipos de la red local que tienen direcciones no válidas para Internet. El equipo Linux rehace la petición poniendo su propia dirección IP y modificando el puerto al que tiene que responder el equipo remoto. Cuando Linux recibe la respuesta del equipo remoto, mira el puerto al que va destinado y vuelve a rehacer el paquete para enviarlo al equipo concreto de la red local que solicitó la conexión. De esta forma podemos mantener un nivel aceptable de protección para los equipos de la red local, ya que sólo podrán recibir respuestas a peticiones que ellos mismos originaron.



Seguridad de Red

La seguridad de las conexiones en red merecen en la actualidad una atención especial, incluso por medios de comunicación no especializados, por el impacto que representan los fallos ante la opinión pública.

El propio desarrollo tanto de Linux, como de la mayoría del software que lo acompaña, es de fuentes abiertas. Podemos ver y estudiar el código. Esto tiene la ventaja de que la seguridad en Linux no sea una mera apariencia, sino que el código está siendo escrutado por muchas personas distintas que rápidamente detectan los fallos y los corrigen con una velocidad asombrosa.

Si además comprendemos los mecanismos que se siguen en las conexiones en red, y mantenemos actualizados nuestros programas, podemos tener un nivel de seguridad y una funcionalidad aceptables.

Tampoco tienen las mismas necesidades de seguridad un equipo doméstico, con conexiones esporádicas a Internet, que un servidor conectado permanentemente y que actúe como pasarela entre una intranet e Internet.

Para describir las pautas de actuación seguras iremos examinando cómo actúan las conexiones y cómo podemos protegerlas.

Seguridad Del Root
A menudo, el mayor enemigo del sistema es el propio administrador del sistema, sí, tiene todos los privilegios y cualquier acción puede ser irreversible y hacerle perder posteriormente mucho más tiempo que el que hubiera perdido por realizar las tareas de forma segura. Puede borrar cualquier fichero e incluso destruir el propio sistema, mientras que un usuario «normal» sólo puede perjudicarse a sí mismo. Por estos motivos, conseguir privilegios de root es la meta de cualquier ataque.

Tampoco hay que alarmarse. Piense que en un sistema operativo monousuario cualquiera podría darle formato al disco duro y perder toda la información almacenada o borrar cuaquier fichero necesario para el funcionamiento del sistema. En un sistema estilo Unix, como Linux, esto sólo lo podría hacer el usuario root.



Protección para la seguridad
La seguridad es un proceso continuo, que requiere tener previsto hasta lo imprevisible. Tener unos buenos hábitos y tomar unas pequeñas precauciones nos ayudarán mucho.
Determinar los servicios activos

Desactive todos los servicios que no vaya a prestar, en particular revise los ficheros /etc/inittab, /etc/inetd.conf y los demonios que se lanzan durante el arranque. Si no está realmente seguro de lo que hace, mejor no haga nada; las distribuciones más modernas incorporan unos mínimos de seguridad aceptables para un usuario medio.
No tiene sentido tener abierto un servicio del que no va a hacer uso ningún usuario legal. Puede que esté consumiendo recursos de su sistema para ofrecer a algún atacante la posibilidad de violarlo.

Puede usar un analizador de puertos para ver qué parte de su sistema es visible desde el exterior. Existen utilidades como SATAN, Nessus o nmap que realizan esta labor.

Trinux es una minidistribución de Linux totalmente portable que se puede llevar en 2 ó 3 disquetes y se ejecuta por completo en RAM, puediéndose usar desde cualquier equipo para la red. Se arranca desde el disquete y no utiliza el disco duro para nada. Contiene las últimas versiones de algunas herramientas muy prácticas enfocadas a la seguridad en redes. Nos permitirá analizar el tráfico de la red, analizar puertos e incluso ver el contenido de los paquetes que circulan por la red.
Proteger los ficheros importantes

Existe un parche para el núcleo Linux que impide que ciertos ficheros puedan ser modificados, incluso por el propio root. El núcleo parcheado de esta forma puede garantizarnos la integridad de la información almacenada incluso en el caso de que alguien consiguiera privilegios de root en nuestro sistema. Este parche se puede obtener, junto con la información necesaria para su instalación, en LIDS.

Si no queremos aplicar el parche, sí que deberíamos vigilar los permisos de ficheros y directorios.
Software actualizado

La gran mayoría del sofware que acompaña a Linux es de código fuente público, como el propio núcleo. Esto es una garantía de seguridad en sí. Cientos de expertos analizan minuciosamente el código para detectar alguna pega que poder publicar en las listas de correo sobre seguridad más prestigiosas, y se corrigen con gran rapidez. De esta forma nos garantizamos un software de calidad y no una mera seguridad aparente. Esto por otro lado nos obliga a ir sustituyendo las versiones defectuosas por otras corregidas y que mejoran las prestaciones. En cualquier sistema operativo, mantener un software que ha demostrado tener fallos supone asumir un riesgo innecesario.

Para estar actualizado consulte los recursos de información sobre seguridad en Linux.
Prevenir pérdidas de información

Existen acontecimientos de los que nos puede resultar muy difícil protegernos como son los desastres naturales, únicamente podremos seguir una serie de pasos para evitar que su incidencia sea lo menor posible. La mejor solución es mantener un buen conjunto de copias de seguridad sobre toda la información necesaria del sistema. Hay que pensar que las copias de seguridad no sólo nos protegen de desastres naturales, también de los desastres que pueda ocasionar algún intruso en nuestro sistema, de cualquier ataque a la disponibilidad o integridad de la información del sistema.

Si los datos tienen un tamaño inferior a 650Mb, puede ser una buena opción grabarlos en un CD, bien permanente (ya que es más difícil de falsificar con posterioridad, y si están almacenados de forma adecuada pueden durar mucho tiempo) o regrabable. 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.

Hay que insistir en la seguridad de las copias de seguridad. Si las copias de seguridad no están almacenadas en un sitio seguro, puede que el posible intruso no tenga necesidad de idear métodos sofisticados para obtenerla, si le basta con copiar o sustraer un CD.
Características de las copias de seguridad

Cuando se realice una copia de seguridad es conveniente seleccionar un método que garantice la conservación de las características de la información como son derechos y permisos. Si realizamos una copia de seguridad de una forma o sobre un soporte que no contemple esta posibilidad, si tenemos que restaurar los datos sobre el sistema el resultado sobre la seguridad y funcionalidad globales puede ser impredecible.
Secuencia de Copias

Es necesario tener un política de copias de seguridad adecuada a las características de la entidad que estamos gestionando. Quizás el mejor método es el de rotación de cintas. Pasamos a verlo con un ejemplo.

Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta para cada Viernes y una cinta para para los Viernes impares. Se realiza 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ía adecuado efectuar una copia.
Copiar las Bases de Datos del Sistema

Existe cierta información del sistema que es imprescindible para su correcto funcionamiento. Es conveniente tener una copia de estos ficheros en una ubicación segura. En particular resulta conveniente tener una copia del contenido del directorio /etc. También hay que mantenerla en lugar seguro, ya que tiene copias de los ficheros /etc/passwd y /etc/shadows, entre otros que puedan contener claves de usuarios que no están cifradas.

También en cada sistema se puede tener una base de datos de las aplicaciones que hay instaladas en el servidor. Cada distribución dispone de alguna herramienta que nos realiza el mantenimiento de la base de datos a la mism vez que instala o desinstala aplicaciones. La pérdida de esta base de datos nos haría perder el control sobre qué aplicaciones tenemos instaladas.

En muchas situaciones también será necesario tener copia de seguridad de los ficheros de registro de incidencias, para tener constancia de las distintas actividades del sistema.
Consejos

    * Suscribirse a las listas de correo de alertas de seguridad para estar actualizado.
    * Prestar atención a los ficheros de registro.
    * Actualizar el software inseguro.
    * Verificar regularmente la integridad de los ficheros con algún software como tripwire.
    * Tener unas copias de seguridad adecuadas.
    * Utilizar PGP o GnuPG para garantizar la autenticidad y la privacidad.
    * Verificar con periodicidad los puertos de los equipos.
    * Revisar periódicamente las cuentas de usuario.
    * Asignar cuotas de uso de recursos del sistema.
    * Mantener los terminales seguros.
    * Asegurarse de tener claves sólidas.
    * Mantener el sistema de ficheros con propietarios y permisos adecuados.
    * Instalar cortafuegos.

En resumen

Ahora, una vez vistas las características generales de seguridad, lo que queda es aplicar el sentido común. Tenemos que ver nuestra situación y respondernos a una serie de preguntas:

    * ¿Qué queremos proteger?
    * ¿Qué valor tiene lo que queremos proteger?
    * ¿Qué coste tiene la seguridad?
    * ¿De quién nos queremos proteger?
    * ¿Cuáles son los puntos débiles de nuestro sistema?

Las posibles respuestas a estas preguntas nos propocionan un abanico de posibilidades demasiado amplio como para poderlo tratar todo.

Lo primero que tenemos que determinar es lo que queremos proteger. No será lo mismo una estación de trabajo personal aislada con conexiones a Internet esporádicas que un servidor web con conexión permanente o un cortafuegos.

También tendremos que considerar el coste de lo que queremos proteger: posible coste económico, tiempo de restauración o instalación, prestigio, perdida de clientes, etc. También el coste de la seguridad en unos términos parecidos a los anteriores. Sería absurdo que invirtiéramos más en protección que el coste de lo protegido.

También hay que considerar que existe una relación inversa entre seguridad y funcionalidad. Cuanto más seguro hacemos un sistema, menos funcional resulta, ofreciendo menos servicios y más limitaciones de acceso. Esto también constituye otro coste adicional: facilidad de uso.

Después de saber qué y de qué tenemos que protegernos, de quiénes y cuáles son sus posibles objetivos, y viendo los servicios que necesariamente hay que prestar o usar, obtendremos un esquema elemental de nuestra situación y de las medidas que tenemos que tomar.


¿Que hacer en caso de Ruptura?
Ahora vamos a ver qué se puede hacer en caso de haber sufrido o estar sufriendo un ataque.

No es una situación agradable, y aunque siempre sería preferible que no hubiera sucedido, conviene tener en mente una serie de normas que nos permitan una actuación rápida y certera que disminuya las consecuencias del incidente. Como norma general hay que conservar la calma. No conviene tomar medidas apresuradas que puedan aumentar el impacto del ataque.

Vamos a distinguir una serie de situaciones posibles y cómo se debe actuar. Una vez visto esto nos queda aplicar el sentido común.
Detección de un ataque activo

Nos ponemos en situación: acabamos de detectar un ataque que está actualmente en curso.

El ataque puede ser de diversa naturaleza. Dejaremos aparte los casos genéricos como detectar alguien manipulando físicamente el ordenador.
Ataque local

Cuando detectamos un ataque local tendremos que verificar la identidad del atacante. No conviene sacar conclusiones precipitadas y culpar a alguien de atacar el sistema cuando sólo puede que sea una negligencia a la hora de seleccionar una clave o abandonar abierta una consola.

Hay que verificar el origen de la conexión, los registros del sistema y los procesos que tiene activos. Tendremos que comprobar si son los habituales y qué es lo que se sale de lo normal. Después nos dirigiremos a esa persona, por teléfono o personalmente, para preguntar qué está haciendo y pedir que cese en la actividad. Si no tiene una conexión activa y no tiene idea de lo que le estamos diciendo, habrá que profundizar en la investigación porque cabe la posibilidad de que alguien haya utilizado esa cuenta de forma ilegítima. Si reconoce el incidente, que le informe de los mecanismos que ha utilizado, las acciones que ha realizado y actúe en consecuencia.

Nunca se precipite para hacer acusaciones. Recopile todas las pruebas que haya detectado en los registros, procesos, modificaciones de información, etc. Sea rápido, pero seguro. Está en juego su sistema y su prestigio.
Ataque en red

Si el ataque se produce a través de la red podemos tener distintas situaciones. En general puede ser conveniente espiar un poco al intruso para obtener más pruebas y después desconectar el interfaz de red si es posible. Si no fuera posible desconectar el interfaz, deberíamos usar algún filtro para las conexiones procedentes de la dirección del atacante. Programas como ipchains (o ipfwadm en su caso) pueden realizar esta labor. Si desconectamos el interfaz o denegamos (no rechazar) los paquetes procedentes de esa dirección el intruso lo podría interpretar como un error de red, más que una detección del ataque. Si no se pudiera limitar el acceso a las direcciones que usa el intruso, intente cerrar 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 posibles puertas traseras.

En general no es aconsejable apagar el sistema. Por supuesto, nunca apagarlo en caliente; esto podría hacernos perder la información que tenemos en memoria. En Linux podemos ver la lista de procesos que hay en ejecución y matar aquellos que puedan estar dañando al sistema.
¿Somos el destino del ataque o somos un punto intermedio?

Se puede dar la situación que nuestra máquina no sea el destino final del ataque. Puede que el intruso la haya utilizado como punto intermedio para atacar a otros sistemas e intentar dificultar el seguimiento de las pistas. En este caso, además de limitar las acciones del atacante deberíamos notificarlo al administrador del destino del ataque y conservar todas las pruebas existentes por si se pudieran reclamar judicialmente.

En cualquier caso, si queremos dar validez legal a las pruebas obtenidas, sería conveniente la intervención judicial.

Es habitual que durante los próximos minutos el atacante vuelva a intentar continuar con sus acciones, tal vez usando una cuenta diferente y/o una dirección de red distinta.
El ataque ha concluido

Ha detectado un compromiso que ya ha ocurrido o bien lo ha detectado mientras ocurría y ha echado al atacante fuera de su sistema.

Ahora viene la parte más dura del incidente: tratar de dejar el sistema mejor que estaba antes de que ocurriera.
Tapar el agujero

Determine los medios que usó el atacante para acceder a su sistema. Deberá analizar cuidadosamente los ficheros de registro del sistema. En ellos debería haber una información valiosa para seguir la pista de las actividades del intruso en nuestra máquina. Las causas más habituales son una mala configuración de algún servicio, un programa defectuoso o la negligencia de algún usuario con respecto a su clave de acceso.

Compruebe por los cauces más conocidos, que se pueden consultar en la página sobre recursos de seguridad bajo Linux, la existencia de algún nuevo «exploit» que pueda ser la causa u otros fallos que tenga que corregir.

Si no elimina al atacante, probablemente volverá. No sólo a su máquina, sino a cualquiera otra de la red. Durante sus incursiones ha podido utilizar algún «sniffer», y disponer de información suficiente para tener acceso a otras máquinas locales.

Si sospecha que el atacante ha obtenido copias de los ficheros /etc/passwd, /etc/shadow, /etc/ppp/pap-secrets, /etc/ppp/chap-secrets o cualquier otro fichero que contenga datos de usuarios y claves, sería conveniente modificarlas todas. Si tiene distintos usuarios en su máquína, oblígueles a cambir su clave. En general es preferible cambiar siempre las claves despues de un incidente, una vez que sepamos que lo hacemos de una forma segura.

Verifique si se han modificado las limitaciones al acceso a distintas herramientas de administración remota como linuxconf. Puede que el atacante trate de abrir alguna puerta trasera para continuar aprovechándose de nuestras máquinas.

En algunos casos puede interesar antes de nada, hacer alguna copia de todo el disco duro para seguir investigando el incidente en otra máquina distinta que no esté conectada a la red y no perder una información que puede ser valiosa.
Evaluación de los efectos del ataque

El siguiente paso que hay que realizar es la evaluación de los efectos que ha tenido el ataque. Tiene que tener en mente la naturaleza del ataque para evaluar los efectos. Si ha sido una denegación de servicio es probable que el atacante no haya tenido acceso a la información local. Si tenía instalado algún programa, estilo Tripwire, que verifica la integridad, su trabajo ahora sería más cómodo. En caso contrario tendrá que verificar todos sus datos importantes. Verifique las fechas de creación de los ficheros binarios y si detecta alguna incongruencia con la fecha de instalación puede empezar a sospechar. Si tiene la posibilidad, compare los tamaños de los ficheros con otro sistema «limpio» y por supuesto, no trate de verificar los programas ejecutándolos como root.

Unas buena alternativa es volver a instalar el sistema. Guarde los ficheros de configuración para tener una funcionalidad idéntica a la previa al ataque. En Linux, los ficheros de configuración se almacenan en modo texto por lo que no son susceptibles de contener caballos de Troya. Eso sí, debería verificar que las configuraciones son las originales y no han sido manipuladas por el atacante. Reinstale el sistema y utilice las copias de seguridad para reponer los datos de los usuarios.

Hay que tener especial cuidado con las copias de seguridad. Tiene que estar seguro de que las copias de seguridad que está utilizando son previas a cualquier ataque. No se arriesgue a restaurar unas copias de seguridad que pudieran tener algún caballo de Troya; tenga un cuidado especial con los ficheros binarios que restaura.
Avisar

Si cree que ha sido objeto de un ataque que no está documentado, debería notificarlo a alguna organización de seguridad como CERT o similar para que se pueda solucionar lo antes posible y evitar que otros sistemas lo puedan padecer.

Y aunque sea un hecho documentado con anterioridad, no dude en pedir consulta a alguna de la múltiples lista de correo que tratan temas de seguridad en general y de Linux en particular. En España resulta especialmente recomendada la lista CERT-ES de RedIris.

Si ha conseguido información sobre el atacante, se lo debería notificar al administrador del dominio del intruso. Puede buscar este contacto con whois, con la base de datos del Internic o en RedIris. Podría enviarles un mensaje de correo con todos los registros relacionados con el incidente, fechas y horas. Si conoce alguna otra información sobre su intruso, podría mencionarla también. En ciertas situaciones, tras enviar el correo podría llamar por teléfono al administrador del sistema que originó el incidente. Si el admininistrador localiza a su atacante, podría hacerle las cosas mucho más fáciles.

Los buenos hackers con frecuencia usan 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 administradores, le puede facilitar la obtención de la ayuda necesaria.

De todas formas, esperamos que la lectura de este capítulo sea totalmente innecesaria, si ha seguido unas normas adecuadas de seguridad.



Recursos
Con esta lista de recursos perseguimos dos objetivos fundamentales, tener una buena guía para saber dónde consultar y obtener información, y por otro lado, obtener la información sobre las novedades que van ocurriendo, nuevos fallos descubiertos, los exploits  que aparecen y los mecanismos para poderlos solucionar.

En SeguriNet se puede encontrar una traducción en castellano de la Guía de Seguridad del Administrador de Linux. En ella tenemos una documentación valiosa donde completar aspectos más concretos, así como una buena lista de recursos.

Por otro lado en CICA tenemos la mejor lista de correo sobre seguridad en castellano que hay sobre linux. No es un foro de discusión, no está pensada para realizar consultas, sino para recibir de forma rápida y clara todos los avisos sobre nuevas vulnerabilidades que se detectan en Linux, los efectos que pueden tener y cómo se pueden solucionar. No queremos desaprovechar la oportunidad de agradecerles el trabajo que realizan. Podéis suscribiros en su página de suscripción a sec-linux@ls.cica.es. CICA cuenta además con otra información interesante que merece la pena consultar.

En las páginas del GLUB hay una buena recopilación de software y documentación de seguridad en Linux en castellano.

RedIris es otro lugar que también dispone de información valiosa y listas sobre seguridad y Linux.
Recursos Web y ftp
Distribuciones

    * Caldera OpenLinux
    * RedHat
    * Guía de errores de RedHat
    * Lista de archivos de seguridad de RedHat
    * SuSE
    * Listas de correo de SuSE
    * Debian
    * Slackware
    * Fórum Slackware
    * TurboLinux
    * Stampede GNU/Linux
    * Mandrake
    * LinuxPPC
    * Linux Pro
    * LinuxWare
    * MKLinux
    * Yggdrasil
    * Connectiva
    * DLD
    * Pacific HiTech TurboLinux Errata Guide
    * Eagle Linux M68K
    * Eurielec
    * Kheops Linux
    * MNIS Linux
    * Trinux (una minidistribución enfocada hacia la seguridad)

Red / Análisis de Host / Intrusion

    * nmap
    * ftpcheck, relaycheck
    * cheops
    * nessus
    * saint
    * SBScan
    * Samba scanner (funciona con windows)
    * HUNT
    * SATAN y otras herramientas

Administración

    * rpm
    * Guiones de actualización RedHat RPM
    * Logcheck
    * bgcheck
    * COAS
    * Webmin
    * Linuxconf
    * super
    * YaST

Cortafuegos

    * ipchains configuración más fácil
    * Configuración de un cortafuegos mediante un CGI
    * ipchains y otros

Servicios de Red

    * sendmail
    * apache
    * BIND/DHCPD/DHCPCD
    * secure syslog
    * openssl
    * ncftp, ncdftp
    * qmail
    * postfix
    * ProFTPD
    * rsync
    * PPP
    * Servicios de internet
    * versión libre de LDAP
    * Lenguaje de programación para generar HTML dinámico

Soluciones para Redes Virtuales Privadas

    * CIPE
    * ECLiPt
    * Productos hardware RedCreek VPN (IPSec)
    * Controladores de tarjetas RedCreek VPN para Linux
    * Desarrollo PPTP para Linux
    * FreeS/WAN, un desarrollo IPSec para Linux

SSL

    * SSLeay
    * Desarrollo open SSL
    * Aplicaciones para SSL
    * Ftp oficial
    * Desarrollo Apache SSL libre

Servicios/Cifrado de datos

    * Desarrollo libre de SSH
    * Sustituto libre de PGP
    * CFS

Herramientas de Seguridad

    * audit
    * Varios paquetes de software de seguridad

Kernel

    * stackguard
    * rule based access control

Detección de intrusos

    * port sentry
    * host sentry
    * Network Flight Recorder

Grupos de respuestas sobre seguridad

    * USA - CERT
    * Información sobre seguridad en castellano
    * INTERNATIONAL - HERT
    * AUSTRALIA - AUSCERT
    * SINGAPORE - SINGCERT
    * Winn Schwartau's site
    * L0pht
    * Root Shell
    * Infowar UK
    * buenos documentos

Programas comerciales para copias de seguridad

    * BRU
    * Quickstart
    * Arkeia
    * CTAR
    * CTAR:NET
    * Backup Professional

Aplicaciones

    * Página de actualización diaria y búsqueda
    * Prácticamente todos los paquete RPM
    * Un gran listado de aplicaciones

Varios

    * Security and Encryption: Probablemente la mejor lista de recursos sobre seguridad en internet. Aquí podrá encontrar casi todo y algo más.
    * Replay tiene archivos de muchos programas de seguridad.
    * Wietse's
    * Ftp de ES-CERT
    * The Hacker FA
    * Bugtraq
    * First
    * Hacking
    * CPSR
    * Underground
    * Defcon
    * El archivo COAST tiene un gran número de programas de seguridad Unix e información.
    * Reptile tiene montones de buena información sobre seguridad en sus páginas.
    * Infilsec tiene un motor de vulnerabilidad que puede decirle cuales afectan a una plataforma específica.
    * CIAC enviós periódicos de seguridad sobre exploits comunes.
    * Un buen buen punto de inicio para Linux Pluggable Authentication Modules (PAM).

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.

Fuente: http://www.iec.csic.es/