OSSEC – Sistema de Detecion de Intrusos Basado en Host

OSSEC es un proyecto open source de gestión de Logs, que monitoriza una máquina, y que detecta las anomalías que puedan producirse en ella. Para hacer esto utiliza  herramientas para la detección de rootkits, para revisar la integridad de ficheros y ejecutables del sistema, y por último un potente sistema para analizar logs. Esta basado en un modelo de cliente-servidor, con lo cual tendremos un servidor centralizado que se encarga de recibir y actuar en base a la información que reciba de los agentes que, en definitiva, son las máquinas que están siendo monitorizadas y atacadas. La forma de actuar del servidor es, por una parte, enviando notificaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes. Funciona en la mayoría de sistemas operativos, incluyendo Linux, OpenBSD, FreeBSD, MacOS, Solaris y Windows, ademas acaba de salir la nueva versión 2.5 de este proyecto, la cual incluye numerosos cambios que hacen de este proyecto una verdadera opción a elegir. Descargar OSSEC 2.5 Mas Información: Pagina Oficial del...

Leer Más

Linux 2.5.25.10 liberado, y lo que piensa Linus de la gente de OpenBSD

Hace una semana fue liberada la nueva versión del kernel de linux. En el correo anunciando su liberación se encuentra un pequeño resumen: > It contains a number of assorted bugfixes all over the tree. And once > again, any users of the 2.6.25 kernel series are STRONGLY encouraged to > upgrade to this release. Lo curioso es que no mencionan muchos detalles acerca de la IMPORTANCIA de actualizar. Entre algunas respuestas al anuncio el equipo de PaX anuncio que dentro de los commits que se habían obviado mencionar se incluían una serie de correcciones al kernel que tenían alto impacto en la seguridad del mismo. (http://lwn.net/Articles/285438/, http://lwn.net/Articles/286263/, http://lwn.net/Articles/287339/, http://lwn.net/Articles/288473/) En la misma discusión se cuestionaron las políticas de manejo de bugs “con impacto de seguridad” en los changelogs y demás notas de versiones, junto con otros aspectos de manejo de documentación al respecto. Esto llevo a que se hiciera hincapié en “la importancia de tener full/none/half/etc disclousures para los bugs que tengan relevancia en la seguridad”, con el siguiente párrafo: so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs? and even more importantly, when will you change your policy or bring your process in line with what you declared? Luego, en un reply de Linus: Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. Y de hecho tiene muy buenas razones para haber dicho eso, ya que la industria de la seguridad informática se ha convertido en todo un teatro donde el que monte la mejor película es el que tiene la razón. Linus dice que los bugs que tienen impacto en la seguridad son bugs normales, y tiene razón, técnicamente nadie diseña bugs en su software, y si tienes un bug probablemente no tengas la oportunidad de elegir si afecta o no en la integridad de la seguridad del kernel. Son bugs normales, y como bugs se deben tratar, más no glorificar el esfuerzo de la persona que lo encontró ya que asi como existe ese bug, hay muchísimos más y de mayor complejidad en el kernel. No hay razón para que exista tal burocracia de tratarlos de manera muy diferente y subirlos sobre un pedestal y escribiendo HOWTO’s para como explotarlos. De todas maneras, esto tambien influye en la comunidad de la seguridad informatica, ya que entre menos full disclousure...

Leer Más

Descubren y arreglan bug de 33 años de edad en Yacc.

Una vez más, el proyecto OpenBSD soluciona uno de los bugs más viejos. Otto Moerbeek, desarrollador del proyecto OpenBSD, ha estado trabajando en una nueva implementación de malloc() con algunas características extra que ayudan a prevenir el desbordamiento de pila. La implementación de malloc() de Otto había estado probándose hasta que Nikolay Sturm reporto que había problemas con SPARC64 cuando se compilaban programas grandes escritos en C++. Por lo general, dichos programas fallaban no por sintaxis sino por un error interno del compilador (ICE, Internal Compliler Error). La nueva implementación de malloc() de Otto tiene algunas características que no se encuentran en ninguna otra implementación: mueve asignaciones de memoria pequeñas que una pagina pero más grandes que la mitad de una pagina al final de la pagina, y así tener mayor chance de atrapar buffer overflows. El bug lo encontró apagando su implementación de malloc() e investigando en SPARC64 hasta que usando una versión con símbolos de depuración del compilador pudo interpretar un backtrace con gdb en donde el compilador moría en yyparse(), una función generada por el generador yacc. El bug solo se dispara en SPARC64, ya que esta arquitectura usa paginas de 8k. El tamaño del stack de yacc por omisión para C++ es de 24 * 200 = 4800 bytes. Más información en BSD...

Leer Más

Siguenos!

O Puedes Subscribete

ANTES DE

SALIRTE ...

NO TE

ARREPENTIRÁS

!Gracias¡

NO OLVIDES NUESTRAS REDES SOCIALES