¿Tiene Rentabilidad matar la innovación?

02 de septiembre 2010 por Chris No hay comentarios »

Paul Graham tiene una excelente escribir sobre por qué Yahoo fue a la quiebra . El artículo completo vale la pena leer, pero aquí hay dos citas elección:

Recuerdo haberle dicho a David Filo a finales de 1998 o principios de 1999, Yahoo debe comprar Google, porque yo y la mayoría de los otros programadores de la compañía estaba utilizando en lugar de Yahoo para la búsqueda. Me dijo que no valía la pena preocuparse. Buscar sólo el 6% de nuestro tráfico, y su crecimiento era del 10% al mes. No valía la pena hacerlo mejor.

Y más tarde Pablo continúa diciendo:

Si las circunstancias hubieran sido diferentes, la gente corriendo Yahoo podría haber dado cuenta antes lo importante era la búsqueda. Pero tuvieron la opaca obstáculo más en el mundo entre ellos y la verdad: el dinero. Mientras los clientes estaban escribiendo grandes cheques para los anuncios de banner, era difícil tomar en serio la búsqueda. Google no tiene que para distraerlos.

En primer lugar, un descargo de responsabilidad: Las opiniones que voy a expresar son míos. No representan, o tienen alguna relación con cualquier organización que he trabajado en el pasado, presente o futuro. Si usted ve una falta de innovación dentro de su organización, sé que he hecho un trabajo para usted, y que estas opiniones son acerca de su organización, les puedo asegurar que no lo son. Son observaciones en relación con una organización completamente diferente.

artículo de Paul es realmente dio en el blanco para mí. Pensando en los últimos años he pasado de consultoría para diversas organizaciones, me di cuenta de un patrón distintivo. El espacio de Internet está llena de empresas que tenían algunas innovaciones interesantes, hecho incursiones en su cuota de mercado, pero luego perdió su camino en busca de mayores ganancias. Se podía ver dentro de la cultura interna de la organización, así como su fachada a la interacción con el público. Una vez cambiado el enfoque del desarrollo a largo plazo para la tecnología de la rentabilidad a corto plazo, la organización comenzó una espiral descendente.

Probablemente uno de los primeros ejemplos más público fue Lotus . Para la gente con tanto pelo gris como yo, usted probablemente recuerda que los programas como el 1-2-3 y las notas de poner el PC en el mapa como el sistema de negocios de clase elección. A principios de los años 90 todo el mundo estaba ejecutando el software Lotus. Por esa época de la historia era muy innovador y funcional. Había un número de años en que, literalmente, cada compañía que hizo el trabajo por ellos tuvieron una gran despliegue de software de Lotus.

Luego, alrededor de mediados de los 90 todo cambió. Nuevos títulos reparado el error en lugar de la tecnología empujó hacia adelante. Un sistema de protección anticopia draconianas se llevó a cabo. Los costos de soporte telefónico y los parches fueron por las nubes. Recuerdo el momento exacto en que decidí que iba a hacer lo que pude para salir de software de Lotus. Yo estaba sentado en espera para cc: Mail de apoyo (el almacén de datos se había dañado otra vez) y me di cuenta que había contratado a un disk jockey para reproducir música y anunciar el tiempo de espera de colas (normalmente 30-60 minutos). Este me dijo que Lotus sabían que tenían problemas técnicos, pero en lugar de abordar la causa raíz, se llevó a cabo de la manera barata y contrató a un animador. Aunque estoy seguro de que este aumento de su rentabilidad a corto plazo, envió gente como yo, que desemboca en el campo de Microsoft.

Por supuesto que no Louts fue el último. Incluso, vistos Microsoft crecen a pasos agigantados hasta el foco cambia de la innovación para copiar la protección y las manchas de la comercialización. SCO cambiado su modelo de negocio de ser una solución de SMB para que los litigantes, y rápidamente se deslizó en el olvido. Incluso se puede ver de nuevo con Oracle. Algunos se quejan de que Oracle compró Sun para no presentar sus innovaciones, sino específicamente a litigar en contra de Google . Es difícil discutir este punto como desde el exterior parece que los demás lo único que han hecho es matar con Sun OpenSolaris , así cortar una gran cantidad de innovación prestados por los programadores externos.

En el artículo de Pablo, él culpa a la causa de la raíz en Yahoo no contratar a los mejores programadores. En mi experiencia, el problema es más profundo que eso. Cuando una empresa entra en esta fase autodestructiva que se centran menos en la contratación de los innovadores (como programadores) y más en la contratación de contadores. El foco cambia de fomentar nuevas ideas para exprimir hasta el último centavo de ganancia a corto plazo. El primer signo suele ser absurda política de cambios. Cubos sólo puede ser decorado de alguna manera cortador de galletas, los ingenieros deben vaciar su propia basura, que gasta más de su contabilidad al día durante nuestro tiempo en lugar de lograr algo realmente, etc etc

Aunque estoy seguro de que algunos contador puede mostrar en un gráfico de barras bastante que este tipo de incrementar la rentabilidad política de cambios, pasan por alto un punto muy importante. Los cambios crear un ambiente que es perjudicial para el pensamiento innovador. La cultura de cambio de todas las garantías, sino que las ideas innovadoras van a fallar, y los pensadores innovadores van a pasar a otras oportunidades. la interacción de Pablo con Yahoo es un excelente ejemplo. Piense en ello como sinónimo de invertir en los alimentos en el supermercado. Adquisición de alimentos baratos se traducirá en la rentabilidad a corto plazo, pero a largo plazo es probable que aumentan dramáticamente sus costos de atención médica . Cuando usted está contando monedas de un centavo es fácil perder de vista el objetivo a largo plazo (como vivir una vida larga y saludable).

Así que el problema es un gran negocio? ¿Es el mantra de que sólo las empresas pequeñas pueden innovar hambre, mientras que las grandes empresas están destinará al fracaso? Personalmente, no creo que esto es cierto. He visto las grandes empresas que son lo suficientemente inteligentes como para crear grupos de reflexión interna para fomentar la innovación. Los mecanismos se ponen en marcha para conseguir que las nuevas ideas flotaban en la parte superior y el fracaso no se convierta en sinónimo de despido. Si bien la rentabilidad sigue siendo importante (y en mi humilde opinión que debería ser), el riesgo creativo teniendo en verticales potenciales de tecnología son el apoyo de la alta dirección. Un gran ejemplo de esto es probablemente Apple. Pasar de las computadoras a los teléfonos fue un cambio importante en su mercado vertical, pero valió la pena con creces.

Al final, creo que realmente se reduce a la cultura corporativa. Lo que mata a una empresa no es su tamaño, pero su capacidad de crianza a largo plazo en lugar de pensar a corto plazo. comprobación rápida cordura, si nota que su organización la contratación de más contadores de los innovadores, que ya puede estar en la espiral descendente.


Ruta de acceso rápido VMware Versus Firewalls lento camino

30 de agosto 2010 por Chris No hay comentarios »

Muchos de nosotros estamos trabajando ahora con firewalls virtuales. Hice un post anterior sobre la fortalezas y debilidades de la seguridad en el mundo virtual , pero hoy quiero hablar acerca de las posibilidades de cortafuegos con VMware. Ha habido mucho entusiasmo en relación con relativamente nuevo de VMware VMsafe API . En concreto, todo el mundo está luchando para crear o implementar servidores de seguridad de la trayectoria rápida. Pero, ¿son todas las implementaciones de vía rápida creados iguales? ¿Existen problemas de seguridad con ir con una solución vía rápida? ¡Entremos y veamos.

Desglose de VMsafe

Con la liberación de la garantía de la API VMsafe, VMware ha ampliado las opciones disponibles para la implementación de seguridad dentro de un ambiente al permitir que los vendedores vSphere para conectar directamente en el hipervisor en el anillo 0. VMsafe consta de tres componentes:

  • VDDK - inspección bloque de disco. API ha sido lanzado públicamente.
  • vCompute - CPU y la memoria de la API. No ha sido hecho público. Desconocidos que tengan acceso terceros, en su caso.
  • vNetwork - API para supervisar / filtro entre la vNIC y vSwitch. No ha sido hecho público. Al mejor de mi conocimiento, sólo Altor Redes y Sistemas Reflex tienen acceso (dos vendedores que participaron en el desarrollo de la API).

En concreto, quiero hablar con el vNetwork API. Cuando el flujo de control del tráfico de red dentro de un host ESX, hay dos posible aplicación, "vía lenta" y "vía rápida".

Lento Camino

Lento es el camino más simple aplicación y la que hemos estado utilizando durante años. En efecto, esto es sólo un invitado VM, similar a cualquier otro invitado VM, corriendo en el host ESX. Normalmente, cada invitado está conectado a un vSwitch único, y cada uno de estos vSwitches está conectado a una única vNIC en el firewall. Esto es similar a una configuración del cortafuegos legado, pero aplicadas de forma virtual. El beneficio de la ejecución en vía lenta es que puede ejecutar un golpe sistema operativo completo con todas las bibliotecas o servicios necesarios para apoyar el firewall.

Ruta de acceso rápido

ruta de acceso rápido es efectivamente un anillo 0 controlador que se conecta directamente en el núcleo hipervisor. Esto permite que un proveedor de terceros para aprovechar el hipervisor para la inserción entre cada conexión vNIC vSwitch /. Debido a que un controlador de vía rápida se está ejecutando en el contexto del núcleo, que implica una sobrecarga mínima en el sistema. El resultado es la ejecución de código dentro de vía rápida es sustancialmente más rápido que el mismo código se ejecuta dentro de vía lenta (por lo que la convención de nomenclatura de VMware para cada contexto). De carga en el host ESX se reduce al mínimo, por lo que el resultado final es que usted puede ejecutar los invitados mucho más virtual.

Vs Lento Rápido

Por lo tanto, suena como si quisiera hacer todo lo recorrido que se encuentra rápido, pero hay una serie de cuestiones. ruta de acceso rápido es un controlador del núcleo enchufarlo a un hipervisor minimizado, no un sistema operativo todo su apogeo. Esto limita las bibliotecas y los servicios del servidor de seguridad tiene a su disposición para controlar el flujo de tráfico. Además, estamos conectando un controlador del núcleo por lo que debe ser la seguridad de que no se hinchan el hipervisor, aumentar la superficie de ataque o interferir con las funciones hipervisor otros. VMware lleva a cabo una revisión de código en todos los controladores de vía rápida antes de su liberación. Así que si teóricamente podría poner en práctica todo mi código en el camino rápido, que iba a necesitar la aprobación de VMware antes de cada parche o versión función.

Con esto en mente, un proveedor reclamando "vía rápida" de apoyo es en realidad va a terminar la aplicación de una parte de su código como vía rápida, una parte como un camino lento, y luego crear un conector entre los dos. ¿Cómo carga mucho se coloca en el sistema dependerá de la cantidad de este código se implementa en el camino rápido y cuánto de ello se ejecuta en el camino lento.

Posibles implementaciones de Fast Path

Por ejemplo, un proveedor puede optar por escribir un controlador de ruta de acceso rápido que simplemente túneles todos los paquetes de nuevo a un camino lento a cabo firewall. El código de vía lenta a continuación, determina si el tráfico se debe pasar o se cae, pasa con los paquetes se envían de nuevo al código de vía rápida para su inserción en el canal de control hipervisor. Si bien este sería el método más fácil de implementar vía rápida, y posiblemente el más segura, proporcionaría los beneficios al rendimiento. La carga del sistema probablemente no sería mucho mejor que una aplicación plena vía lenta. Veo esta opción como muy atractiva para los vendedores de firewall legado, ya que requeriría la menor cantidad de modificaciones a su código existente ya la vez poder para reclamar "apoyo vía rápida".

Otra opción sería utilizar el espacio de vía lenta para las funciones administrativas con el controlador de ruta de acción rápida como el motor de firewall. Así, por ejemplo el administrador del cortafuegos crearía la política mediante una interfaz que se ejecutan en un camino lento VM, que luego llevaría a la política de abajo a un controlador de ruta de acceso rápido. En esta configuración del controlador de vía rápida tiene una copia de la política para el control del tráfico pueden ser aplicadas de inmediato. El resultado es más rápido manejo de tráfico con la carga mínima del sistema. La compensación es más abultado código en el anillo 0.

También es posible aplicar una mezcla de los dos. Por ejemplo, yo podría utilizar el controlador de ruta de acceso rápido para aplicar la directiva de firewall, pero a continuación, pasar todos los "aceptado" los paquetes de nuevo al sistema vía lenta para el control de intrusión, detección de virus, o lo que es necesario. Aceptable paquetes se pasan de nuevo al controlador de vía rápida para la inserción. Así que en esta configuración todos "caído" paquetes se manejan a través de vía rápida, mientras que los paquetes aceptados interactuar con un componente de trazado lento.

Como nota al margen, es necesario mantener la información anterior en mente cuando se consideran todas las implementaciones vNetwork, no sólo los cortafuegos. El vNetwork API también se puede utilizar para la aplicación de políticas, calidad de servicio, la recolección de estadísticas de red, etc Por ejemplo, la aplicación vNetwork primera fue en realidad Laboratorio de VMWare Manager. Esta herramienta se utiliza para el servicio de auto aprovisionamiento y no contiene un componente de servidor de seguridad (esto se implementa a través de VShield).

Resumen

Mientras que un producto que se integra con VMware VMsafe estrictamente puede ser una ruta "lenta" la aplicación, es muy poco probable que cualquier producto puede ser considerado sólo una ruta de acceso "rápido" de aplicación. Cualquier producto vía rápida es más probable que va a ser un híbrido. Es sólo una cuestión de cantidad de código existe en la ruta de acceso "rápido" el espacio frente a la "vía lenta" del espacio. Cuando un producto reclamaciones de apoyo vía rápida, tiene que cavar un poco más profundo para analizar la aplicación a fin de identificar los beneficios de rendimiento real.

La estafa de Comcast

25 de agosto 2010 por Chris No hay comentarios »

Nada que ver con la seguridad, pero se sorprendió cuando esto le sucedió a mí, así que pensé que iba a tirar las cabezas para arriba.

Cuando usted paga su tarjeta de crédito o una hipoteca, hay leyes en vigor para (intentar) mantener el alza de los acreedores de usted. Por ejemplo, si usted hace un pago con tarjeta de crédito, el acreedor tiene que solicitar que el pago a la más antigua de compra. Si no, fácilmente podría golpear con mayor interés y la imposición de sanciones sólo pagar sus compras recientes. La ley está diseñada para proporcionar un cierto nivel de protección de los consumidores.

Al parecer, las mismas reglas no se aplican a Comcast. En junio fui a la oficina local de Comcast y cogió dos cajas de cable nuevo. Estas se hicieron en mi factura de junio, que estoy totalmente perdido debido a los viajes. Yo tengo mi configuración banco a hacer auto-pagos, pero el auto-pago junio terminaron siendo $ 18 corto. Saltar a julio y tuve el mismo problema. ¿No mirar el proyecto de ley y dejar de auto-pago haga su trabajo. Sólo que ahora no es sólo $ 18 una palabra, es $ 18 más tasas y sanciones.

Así que aquí estamos en agosto. Menos de 30 días desde la última vez realizado el pago y Comcast mató a mi servicio. Teléfono, TV e Internet a todos fuera de línea. Cuando llamé para saber el problema, me dijeron que mi cuenta fue de 60 días de vencidos. Después de hablar con tres personas diferentes me dijeron que Comcast no tiene tal obligación de aplicar los pagos a los más mayores deudas. Así, mientras que mi factura de julio fue considerado en situación regular, mi factura junio se consideró 60 días atrasados. Así, la interrupción en el servicio, así como a múltiples tasas para enderezar la cosa y fuera. Si Comcast se celebró a las mismas normas que la mayoría de los acreedores, yo tendría que pagar los $ 18. Debido a que no lo son, con su estructura de tarifas que ahora debe $ 47 y ese número sigue aumentando (al parecer su servicio Tivo no se puede encender de nuevo sin un servicio técnico).

Autopsia

  • Agrupación servicios para el hogar puede ahorrar dinero, pero lo convierte en un punto único de fallo desagradable
  • Sea cuidadoso con uno del Banco de automóviles basado en pagar las facturas que pueden variar
  • estructura de Comcast tarifa les permite ganar una tasa de rendimiento anual de 967% si son tanto como $ 1 atrasados y te lo pierdas el mes siguiente

Es la marea de inflexión?

03 de junio 2010 por Chris No hay comentarios »

He estado diciendo por años que el anti-virus ya no es eficaz y que una buena postura de seguridad debe incluir el listado de aplicaciones en blanco. He aquí una cita fresco de George Kurtz, director de tecnología de McAfee:

"No se puede confiar en el software de antivirus - y somos una compañía antivirus. Y cortafuegos por sí solos no proporcionan una protección adecuada ", dijo.

Antivirus, cortafuegos y detección de intrusos son un comienzo. Pero "lista blanca" ofrece una defensa más fuerte. Esto es, esencialmente, por los equipos de bloqueo de manera que sólo los programas de confianza se pueden ejecutar. Nada puede ser cambiado o añadido o actualizado, excepto por un administrador del sistema.

McAfee cree que "ahí es donde el futuro se va", dijo Kurtz.

Enlace a la noticia completa

De moda tarde a la fiesta, pero yo lo llevo. ;-)

Son sistemas virtualizados más o menos seguro?

18 de mayo 2010 por Chris No hay comentarios »

He tenido la pregunta anterior pregunta número suficiente de veces que me pareció digno de una entrada de blog. Si bien hace unos años la respuesta puede haber sido "menos seguro", hoy la respuesta es "tanto". Lo sé, suena como Chris están sin compromiso, pero esa respuesta realmente la mayoría de describir con precisión el estado actual de la tecnología.

Virtualización Everything Changes

He escuchado un comentario de pocas personas que la virtualización está a punto de impacto de la industria de la misma manera que Internet hizo en los años 90. Para ser honesto, creo que hay mérito en dicho dictamen. A principios de los años 90 la mayoría de personas corrían IPX, AppleTalk, NetBUI y una plétora de otros protocolos de redes cerradas. A finales de los años 90, la mayoría de la gente corrían IP exclusivamente con conectividad a todo el mundo. La manera de hacer las cosas, así como la forma en que aplica la seguridad, totalmente cambiado a lo largo que 10 años. Tanto la administración de redes y capacidades de seguridad que se de vanguardia en 1990 fueron casi inútiles para el año 1999.

La virtualización está empezando a desarrollarse de tener el mismo impacto en la industria. el despliegue de virtualización requiere un replanteamiento completo de cómo aplicar la seguridad. administradores de regreso en la década de 1990, que simplemente se conecta a Internet, sin tener en cuenta cómo podría afectar su red, se quemó a lo grande. Estamos haciendo fila para ver un resultado similar a la gente adoptar la virtualización.

¿Qué hace que la virtualización menos seguro

El talón de Aquiles de la virtualización en el propio software. Esperamos que podemos confiar en el software para mantener los sistemas de evaluación de distancia el uno del otro, así como el organizador y / o hipervisor. Hay dos problemas importantes con esta expectativa:

  1. Ningún software es libre de bugs
  2. El software puede ser configurado incorrectamente

Hace unos años Básico de Investigaciones mostraron que podían salir de un huésped y obtener el control completo del sistema operativo anfitrión . Mientras que un hipervisor se supone limitar ese tipo de exposición, ciertamente hemos visto casos donde incluso ha sido el hipervisor por alto . Incluso hemos visto casos se convierte en software de explotación sólo cuando se ejecuta en un entorno virtualizado . Estos enlaces muestran una pequeña sección transversal de los problemas de virtualización que se han descubierto en los últimos años. Google le puede dar una lista más completa si usted está interesado.

Así que un profesional de la seguridad prudente va a ser cautelosos de seguir ciegamente confiando en el software sea seguro. El problema es los vendedores no siempre tienen el mismo enfoque. Tome VMware con sus ESX (que pronto serán ESXi) producto como un ejemplo. Muchos de nosotros estábamos atónitos cuando un representante de VMware anunció en CanSecWest que era teóricamente imposible atacar el hipervisor ESX . Cuando simplemente asumir que algo es irrompible, alguien más creativo que va a encontrar una manera de atravesar .

Una de mis mayores preocupaciones con ESX / ESXi es que VMware ha diseñado para ser modular (a través de VMsafe ). En el lado positivo, esto significa que los proveedores externos pueden crear productos para ayudar a mejorar la funcionalidad del hipervisor y la seguridad. En el lado negativo de este aumenta dramáticamente las posibilidades de mal código que se introduzcan que pueden comprometer la seguridad.

Hemos visto un gran ejemplo de esto en el pasado. Marcus Ranum creó el cortafuegos Gauntlet, que en aquella época era uno de los glúteos y patear asegurar los dispositivos de seguridad más disponibles. Cuando tres organismos carta quería la mejor seguridad, se dirigieron a Gauntlet. Marcus vendió guante a Network Associates (McAfee más tarde se convirtió), quien de inmediato empezó a añadir en características. No pasó mucho tiempo antes de una cadena constante de las vulnerabilidades se están descubriendo, cada uno introducido por estas nuevas "características". A partir de ahí, el producto pierde su credibilidad y la seguridad se salió del radar.

Ahora bien, es ciertamente posible para agregar características y mantener las cosas seguras. El FreeBSD gente es un excelente ejemplo de cómo hacer esto correctamente. Para garantizar la seguridad mantienen un estricto proceso de auditoría muy . ¿Es perfecto? No, en absoluto, pero su proceso de auditoría ha definido el estándar para la aplicación de software seguro. Con un poco de suerte VMware hará similar, pero no he escuchado ningún rumor sobre este ser el caso.

Cómo hacer llegar su Jefe Directo

OK, entonces no podemos confiar en el software de virtualización a ciegas para mantener a raya a los atacantes. Sin embargo, podemos aún tomar precauciones para ayudar a minimizar el impacto si lo peor ocurre. Uno de los mayores pasos que puede tomar es considerar cuidadosamente qué servidores alojados obtener, y qué otros sistemas de evaluación se pueden circular por la misma caja. El concepto de zona de seguridad utilizado por los arquitectos de la red es tan aplicable en este caso.

Una zona de seguridad es simplemente un conjunto de sistemas que comparten el mismo nivel relativo de riesgo. Por ejemplo Web, el nombre y los servidores SMTP generalmente se localizan en una zona de despeje, porque corren el riesgo todos comparten similares de ataque directo. En la parte interna de la red, equipos de escritorio se colocan generalmente en una zona de seguridad diferente que los servidores. Esto es porque los servidores tienen poco o ningún acceso a la Internet, mientras que equipos de escritorio suelen ser autorizados a divulgar en forma directa. Esto coloca a los escritorios en mayor riesgo de ataque de los servidores.

Podemos aplicar la misma lógica en la aplicación de virtualización. Un servidor DMZ y un servidor interno no deben ser invitados en el mismo hardware (tanto de la CPU y matriz de disco). Si lo hace, podría permitir a un atacante crear una ruta alternativa en nuestra red. En lugar de tener que pasar a través de cualquier firewall, NIDS, NIPS, aparatos, etc que se ha desplegado en el alambre, un atacante puede obtener acceso a los recursos internos a través del software de virtualización. ¿Es un ataque fácil? No es usted de lo que hemos visto hasta ahora. exploits funcionales se han descubierto sin embargo, ¿por qué introducir un riesgo innecesario si no tiene que hacerlo.

Por cierto, estas normas de seguridad misma zona se debe aplicar a su equipo de red virtualizados. Por ejemplo, es una mala idea utilizar el modificador mismas características físicas a la VLAN la zona desmilitarizada y la red interna. He visto un par de clientes se golpeó de esa manera.

¿Qué hace que la virtualización más seguro

Afortunadamente, desde una perspectiva de seguridad, la virtualización no todo son malas noticias. De hecho, hay algunas prácticas de seguridad muy fresco se puede aplicar en un entorno virtualizado que simplemente no pueden prescindir de él. Esta fue una de las razones que comenzamos a utilizar la virtualización dentro de la Honeynet ya en 2000.

Una de las cuestiones de seguridad más grande que enfrentamos hoy es el nivel del kernel rootkits . ¿Qué hace que esta cepa de malware dañino puede ser eficaz resulta el propio sistema operativo en malware. Esto hace extremadamente difícil la detección, ya que todos los controles de seguridad debe pasar por el núcleo. Si el núcleo está comprometida, no podemos confiar en el núcleo de informar con precisión la información de seguridad. Terminamos teniendo que apagar el sistema, monte la unidad en la que se sabe una limpia del sistema operativo, y la realización de nuestros cheques forenses de allí. Oh por supuesto, el problema con este proceso es que no escala bien. Si tenemos decenas o cientos de servidores, simplemente no hay suficiente tiempo en un día para comprobar todos correctamente.

Como se mencionó anteriormente, VMware está permitiendo el acceso de terceros fabricantes a través del hipervisor API VMsafe. Esto permite el acceso a la información privilegiada del Estado, como la memoria y el tráfico de red, en cada uno de los sistemas operativos invitados. Al enchufar el cargador en hipervisor, algunas opciones de seguridad extremadamente frío se hacen posibles.

Por ejemplo digamos que un sistema operativo invitado es atacado por un rootkit a nivel de kernel. Mediante el análisis de la memoria del invitado, el rootkit puede detectarse desde el exterior del sistema operativo virtual. Al realizar los controles a través del hipervisor, es mucho menos de la posibilidad de que un rootkit puede sigilo de sus actividades y no se detectan. Como se mencionó anteriormente, no hay ninguna opción comparable a un sistema no virtualizado.

El enchufe de la API también crea nuevas posibilidades para tratar con el tráfico cifrado. Cuando un extremo a otro de cifrado se utiliza (como una red privada virtual), el control basado en red de la capa de aplicación son fácilmente pasado por alto. Su única opción real era correr software de agente en el punto final, lo que la seguridad podría aplicarse después de que el proceso de descifrado. Por supuesto, el problema aquí es que si el agente es atacada, todas las apuestas están apagadas. Una vez más, al conectar en el hipervisor estamos en una mejor posición para controlar de forma más segura de estos datos.

Estamos empezando a ver nuevos productos que aprovechan la API VMsafe enchufe . Dado que todos los productos son relativamente nuevos, el jurado está todavía fuera de su eficacia puede ser. Ofertas de ejecutar el gambito de la sustitución de firewall basado en host y la protección IDS para la aplicación de políticas completa. Será interesante ver cómo este nicho de productos sacude durante el próximo año.

Resumen

Así como he mencionado al principio de éste post, la virtualización tiene la capacidad de hacer que su entorno sea más o menos seguro, dependiendo de cómo implementarla. Si simplemente empezar a publicar todo en una sola caja, es probable que va a conseguir golpeado. Si extiende las mejores prácticas que se han desarrollado a lo largo de los años en el reino de virtualización, así como aprovechar algunas de las nuevas características de seguridad que están siendo puestos en libertad, en realidad se puede crear una mejor postura de seguridad global.

La combinación de Logwatch y OSSEC - Parte 4

18 de febrero 2010 por Chris 3 comentarios »

En mi último post que instalamos Logwatch así como OSSEC. Es tiempo de poner Logwatch OSSEC y jugar juntos en la misma caja de arena. En este post voy a hablar de cómo obtener Logwatch para resumir la información generada por OSSEC.

Opciones de implementación

Tenemos dos caminos que puede seguir para instalar esto:

  1. Ha Logwatch analizar los registros de OSSEC directamente.
  2. Ha OSSEC enviar su alerta sobre un tipo de servidor Syslog, a continuación, ejecute Logwatch en el servidor de Syslog.

El beneficio para la opción # 1 es que sólo necesitamos un sistema. Logwatch se llevará a cabo en el sistema que aloja el servidor de OSSEC. El problema que se va a ejecutar en el archivo sin embargo implica OSSEC alerta. Las entradas de registro no se normalizó. Esto significa que el formato puede cambiar de entrada a la entrada, e incluso se puede propagar a través de líneas múltiples. Va a ser una verdadera pesadilla para crear una secuencia de comandos Logwatch que filtrar y resumir la información de alerta.

Si vamos con la opción # 2, se requerirá otra caja para que actúe como nuestro servidor de registro centralizado. Con el fin de hacer que el servidor OSSEC aceptar entradas de registro de los sistemas no-agente, tiene que escuchar en UDP/514. Este es el mismo puerto que utiliza un servidor de registro centralizado, y usted no puede tener dos aplicaciones comparten el mismo puerto (excepto con Windows, pero el acceso es muy complicado zócalo). En el lado positivo, las entradas de alerta se recibe normalizada cuando se transmite al servidor de Syslog para la creación de un script resumen Logwatch será mucho más fácil. Además, Logwatch ya sabe acerca de los archivos syslog estándar, por lo que tendrán menos trabajo de personalización que hacer.

Por último, mencioné en un post anterior que OSSEC no está diseñado para ser una tarjeta SIM. Esto se debe a que no todo registro, sólo los eventos que generan una alerta. Así que probablemente va a querer un servidor centralizado de todos modos, y tiene sentido de tener que almacenar la información generada por OSSEC.

Así que si suena como que estoy de dirección hacia la opción # 2, que son absolutamente correctas. Dicho esto, estoy realmente va a cubrir la opción # 1, ya que es la configuración mucho más compleja.

Lidiando con fecha / hora

Echa un vistazo a los principales logfile OSSEC y usted debería ver similar a lo siguiente:

[root @ fubar registros] # tail -3 / var / OSSEC / logs / ossec.log

2010/02/18 12:32:05 OSSEC-rootcheck: INFORMACIÓN: Poner fin a rootcheck exploración.

2010/02/18 14:27:06 OSSEC-syscheckd: INFORMACIÓN: A partir SysCheck exploración.

2010/02/18 14:39:21 OSSEC-syscheckd: INFORMACIÓN: Acabar con SysCheck exploración.

Tenga en cuenta la forma en la fecha y hora tiene el formato. Esto es diferente a la mayoría de aplicaciones, así que lo primero que tendremos que hacer es decirle a Logwatch cómo tratar con este formato. Tendremos que crear un script que podemos llamar cuando sea necesario que leen el formato indicado anteriormente.

Primer paso es colocar en el directorio compartido secuencias de comandos:

cd / usr / share / Logwatch / scripts / shared

Utilizando su editor favorito, cree un archivo llamado "applylongdate":

vi applylongdate

Esto es lo que necesito dentro de ese archivo. Siéntase libre de copiar / pegar desde esta página:

uso Logwatch ': fechas »;

my $ Debug = $ ENV ('LOGWATCH_DEBUG') | | 0;

$ SearchDate TimeFilter = ('Y% /% m /% d% H:% M:% S');

if ($ Depurar> 5) (

imprimir STDERR "DEBUG: n Dentro ApplyLongDate ... \";

imprimir STDERR "DEBUG: Buscando:". SearchDate $. "\ N";

)

while (defined ($ ThisLine recoger con <STDIN> =)) (

if ($ ThisLine = ~ m / ^ $ SearchDate / o) (

print $ ThisLine = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ ThisLine;

)

)

# Vi: tabulación = 3 sintaxis TabStop = = 3 y perl

Una vez que usted guarde el archivo, ahora tenemos que establecer los permisos adecuados:

chmod 755 applylongdate

Configurar el registro de archivos

Lo siguiente que necesitamos decirle a Logwatch en los archivos de registro se encuentran OSSEC. Cada vez que añada nuevos ficheros de registro o crear nuevos servicios, para controlar en Logwatch, usted debe colocar sus cambios en el directorio / etc Logwatch /. Vamos a crear dos archivos de configuración. El primero se encargará de mensajes OSSEC, y el segundo se ocupará de las alertas y los cambios OSSEC respuesta activa.

Comencemos por crear el archivo de configuración para el registro principal de OSSEC archivo:

cd / etc / Logwatch / conf / archivos de registro

vi ossec.conf

El contenido del archivo debe ser como sigue:

LogFile = / var / OSSEC / logs / ossec.log

* = ApplyLongDate

Ahora puede guardar y salir del archivo. A continuación, vamos a crear el archivo de configuración para el resto de los archivos de registro:

vi OSSEC-alert.conf

El contenido de este archivo debe ser como sigue:

LogFile = / var / OSSEC / logs / activo responses.log

LogFile = / var / OSSEC / logs y alertas / alerts.log

LogFile = / var / OSSEC / logs / firewall firewall.log /

Una vez terminado, guardar y salir. Los permisos por defecto debe ser aceptable para nuestra configuración.

Configuración de servicios OSSEC

A continuación, tenemos que definir los servicios OSSEC e identificar lo que desea utilizar como título cuando los informes se generan. He aquí cómo crear el primer archivo:

cd / etc / Logwatch / conf / servicios

vi ossec.conf

El contenido de este archivo es muy sencillo:

Título = "Mensajes OSSEC"

LogFile = OSSEC

Una vez terminada, se puede guardar y salir. Tenemos que crear un archivo de más en este directorio:

vi OSSEC-alert.conf

El contenido de este archivo debe ser:

Título = "OSSEC alertas"

LogFile = OSSEC de alerta

Una vez terminado, guardar y salir, como de costumbre.

Analizar Las entradas

A continuación, debemos decirle a Logwatch cómo dar formato a las entradas del registro en el informe. Tendremos que crear un script de personalización para cada grupo de servicios. Vamos a empezar con un script de prueba suministrado Logwatch; sólo para asegurarse que todo funciona.

Primer paso es colocar en el directorio correspondiente:

cd / etc / Logwatch / scripts / servicios

Utilice su editor preferido para crear tu primer guión:

vi OSSEC

El contenido de la secuencia de comandos debe ser como sigue:

#! / Bin / bash

# Este es el guion que le mostrará las líneas que se

# Se procesamiento y presentación de informes sobre. En primer lugar, se mostrará el

# Variables de entorno estándar y luego se STDIN y

# Volcado de ella hacia atrás a en STDOUT.

# Estas son las variables de entorno estándar. Se puede definir

# Más en su archivo de configuración de servicios (véase más arriba).

echo "Intervalo de tiempo: $ LOGWATCH_DATE_RANGE"

echo "Nivel de detalle: $ LOGWATCH_DETAIL_LEVEL"

echo "Directorio temporal: $ LOGWATCH_TEMP_DIR"

echo "el nivel de depuración: $ LOGWATCH_DEBUG"

# Desde aquí, tomar STDIN y lo descarga en STDOUT

gato

Ahora cree su segunda secuencia de comandos:

vi OSSEC de alerta

e incluyen el mismo contenido exacto:

#! / Bin / bash

# Este es el guion que le mostrará las líneas que se

# Se procesamiento y presentación de informes sobre. En primer lugar, se mostrará el

# Variables de entorno estándar y luego se STDIN y

# Volcado de ella hacia atrás a en STDOUT.

# Estas son las variables de entorno estándar. Se puede definir

# Más en su archivo de configuración de servicios (véase más arriba).

echo "Intervalo de tiempo: $ LOGWATCH_DATE_RANGE"

echo "Nivel de detalle: $ LOGWATCH_DETAIL_LEVEL"

echo "Directorio temporal: $ LOGWATCH_TEMP_DIR"

echo "el nivel de depuración: $ LOGWATCH_DEBUG"

# Desde aquí, tomar STDIN y lo descarga en STDOUT

gato

Por último, tenemos que establecer los permisos adecuados:

chmod 755 * OSSEC

Prueba de la configuración

La forma más fácil de probar nuestra nueva configuración es ejecutar el comando:

| Logwatch menos

Si sólo desea ver los cambios, puede ejecutar un informe sobre cada servicio, uno a la vez:

OSSEC Logwatch servicio | less

Logwatch servicio OSSEC alerta | less

Además de personalización

Una vez que todos los que trabajan por encima de, usted puede centrarse en conseguir Logwatch para filtrar y resumir las entradas del registro. Logwatch es bastante flexible, y usted puede personalizar la salida de la forma que desee. Una de las cosas agradables sobre el script de prueba por encima de lo anterior es que se le muestra exactamente lo que tiene que trabajar. Así que con un poco de magia expresión regular que puede resumir las entradas según considere oportuno. Para algunas ideas, echa un vistazo a los archivos ubicados en:

/ Usr / share / Logwatch / scripts / servicios

Estos son los scripts por defecto incluido en resumen Logwatch. En concreto, echar un vistazo a los archivos "pam" y "sshd". Ellos son grandes ejemplos de ambos un sencillo y un complejo conjunto de filtros de síntesis.

A medida que desarrolla sus secuencias de comandos, preste mucha atención a los $ LOGWATCH_DETAIL_LEVEL variable ". Esto le permitirá personalizar el nivel de salida del informe según la cantidad de nivel de detalle que el usuario está buscando. Por ejemplo, mientras usted todavía está en el directorio de servicios anteriores, ejecute el siguiente comando:

menos sshd

Cuando la primera página del contenido del archivo se muestra, escriba:

/ Detalle clave> <Introducir

La barra invertida nos permite buscar en el archivo de una cadena de texto en particular. En este caso estamos buscando la palabra "detalle". Una vez que usted presione Enter, se saltará la búsqueda en el archivo hasta que encuentra la primera instancia de la cadena de texto. También pondrá de relieve la cadena de búsqueda. En el primer partido te darás cuenta de que el autor asigna a la variable "$ Detalle" para ser la misma que la variable $ LOGWATCH_DETAIL_LEVEL ". Esto es para ahorrar un poco de mecanografía.

Ahora pulse la tecla de barra invertida nuevo, seguida de la tecla Enter. Esto salta a través del archivo a la siguiente instancia de "Detalle". Usted debe ver:

if ($> Detalle = 20) (

$ Usuario ($ usuario) ($ host)) ($ Método + +;

Else ()

if ($ host! ~ / $ IgnoreHost /) (

$ $ (Usuario) (usuario) ($ host "(todos los )"}++;

Nota del autor proporciona más información si el nivel de detalle se establece en 20 (a medio camino entre baja y media) o superior. Mantenga saltar a través del archivo y podrás ver otros ejemplos en que el autor de apalancamiento esta técnica.

Ahora una página hasta el final del archivo y usted debería ver la siguiente afirmación:

if (% claves OtherList) (

print "\ n ** ** Las entradas no coincidentes \ n";

print "$ _: $ ($ _ OtherList) (s) \ n" foreach% claves OtherList;

)

Esta sección es muy importante, ya que es un cajón de sastre final. Piense en una directiva de firewall por un momento. La mayoría de nosotros crear una regla final que dice: "Si no me permiten específicamente a través de un patrón de tráfico, lo niegan". En otras palabras, si sucede algo inesperado, así es como quiero que se encargue.

La afirmación anterior tiene el mismo propósito al analizar el archivo de registro. Todas las anteriores "si" declaraciones intentará hacer coincidir una cadena de texto específica en la entrada de registro con el fin de darle formato correctamente. Esta entrada dice "Si no se han emparejado y se imprime una entrada de registro específico, sin embargo, imprimirlo en una sección titulada" ** ** Las entradas no coincidentes ". Este paso es muy importante porque sin ella nunca veremos entradas inesperadas. Se las entradas inesperadas que son probablemente los más importantes y más interesantes.

Resumen Exec

Ambos OSSEC y Logwatch son excelentes herramientas de cortesía. OSSEC sobresale en la advertencia de que cuando un patrón de ataque conocido se lleva a cabo. Logwatch es una herramienta fabulosa para resumir un pedazo de tiempo de los registros para los seres humanos en realidad puede darle sentido a lo que está pasando. Mediante la combinación de las dos herramientas que puede crear una defensa mucho más sólida postura en profundidad. El conjunto es mayor que la suma de las partes.

La combinación de Logwatch y OSSEC - Parte 3

17 de febrero 2010 por Chris No hay comentarios »

En mis dos últimos puestos y yo discutimos Logwatch OSSEC, así como la forma en que se puede aprovechar para aumentar su seguridad. En esta entrega hablaré sobre cómo instalar estas dos herramientas.

Instalación Logwatch

Logwatch es bastante fácil de instalar. De hecho, se instala por defecto en muchas distribuciones de Linux, por lo que ya tenga una copia en su sistema. Para comprobarlo, de inicio de sesión como root e intente ejecutar Logwatch con la opción "-v" del interruptor. Si usted ve:

[root @] Logwatch fubar Logwatch #-v

Logwatch 7.3.6 (publicado 05/19/07)

Logwatch está instalado y tiene una copia de la última versión. Si no tienes la última versión, lo pueda levantar de la página de descarga Logwatch .

Hay tres sabores de Logwatch que se puede descargar; binarios en formato RPM, fuente en formato RPM, o la fuente en una bola de alquitrán. Si su sistema soporta la gestión de paquetes RPM, el RPM binario es su mejor opción. Es fácil de instalar y RPM actualizará automáticamente el software cuando las nuevas versiones están disponibles.

Instalación de RPM Logwatch

Para instalar la versión binaria de la RPM, simplemente inicie una sesión como root y vaya al directorio donde descargó el archivo RPM. Ahora ejecuta el comando:

Logwatch rpm-U-7.3.6-1.noarch.rpm

No olvide que puede usar la tecla tab para autocompletar el nombre de archivo en lugar de tener que escribir toda la cosa.

Instalación Logwatch De Fuente

Instalación desde el código fuente está consumiendo un poco más de tiempo. Recuerde que para poder instalar el código fuente que ya debe tener un compilador (como gcc) instalado en su sistema. Inicio de sesión como root y vaya al directorio donde descargó el balón de alquitrán. Para extraer el archivo, ejecute el comando:

tar xvzf Logwatch-7.3.6.tar.gz

Verá una estructura de directorios por debajo de su ubicación actual y se crean un montón de archivos que se copian pulg Ahora tenemos que entrar en el directorio superior que se creó:

cd Logwatch-7.3.6

Para que Logwatch a correr, hay un montón de directorios que se deben crear en su sistema. Estos se documentan en el archivo README en el directorio actual. Por suerte, Logwatch incluye un script de instalación que se puede hacer todo el trabajo por usted. Por desgracia, el guión tiene los permisos establecidos mal para que no se ejecuta por defecto. Esto es bastante fácil de solucionar, aunque con el comando chmod:

chmod 500 install_logwatch.sh

Ahora podemos ejecutar el script de configuración de nuestro sistema:

. / Install_logwatch.sh

No te olvides el punto al principio de la línea.

Pruebas Logwatch

Para probar la configuración de su Logwatch, ejecute el comando:

| Logwatch menos

Verá la pantalla de su terminal en blanco, pero eso es normal. Eventualmente se verá un informe Logwatch se imprimen a la pantalla que se puede navegar a través del uso de la "Page Up" y "Page Down" llaves. ¿Cómo registro que se necesita para el informe que aparece en la pantalla dependerá de la cantidad de información de registro para obtener las necesidades analizadas. Podría tomar unos cuantos segundos o un par de minutos. De cualquier manera, le dará la oportunidad de familiarizarse con el formato del informe.

Instalación OSSEC

Como ya he mencionado en mi último post, tiene dos opciones de instalación con OSSEC, locales o cliente / servidor. En este post voy a centrarse en el cliente y configuración del servidor, ya que es un poco más complejo. Si está realizando una instalación local, sólo tiene que seleccionar el "local" opción durante el proceso de instalación y omitir la sección sobre la creación de un canal seguro entre el agente y el servidor.

Iniciar con el servidor

OSSEC utiliza el cifrado Blowfish para garantizar la comunicación entre el cliente y el servidor. Blowfish es simétrica clave basada, por lo que ambas partes deben saber qué valor de la clave a utilizar para comunicarse. El servidor se encarga de generar la clave simétrica, por lo que tiene que instalar primero el software de servidor. Durante la instalación del cliente que se le solicitará un valor de clave así que obviamente tendremos que tenerlos a mano antes de tiempo.

Aquí hay un ahorro de tiempo extremo. El valor clave es largo y casi imposible de recordar. The easiest way to move the key value from the server system to the agent system is to use SSH. Create a secure connection to the OSSEC server, and extract the appropriate key (directions provided below). In a second terminal window, create an SSH session to the system where you will be installing the agent. When the client install prompts you for the key value, you can simply copy/paste between the two terminals.

Installing The OSSEC Server

The server software is available as a Tar ball, so you can grab a copy of the latest version from the OSSEC download page . You will then need to extract the contents of the Tar ball:

tar xvzf ossec-hids-2.3.tar.gz

Next, move into the directory structure you just created:

cd ossec-hids-2.3

OSSEC provides an install script to walk you through the process of installing the server. To start the script, type:

./install.sh

Don't forget the period at the beginning of the command. You will now be prompted through a number of install options:

  • Language – The default is English. Change as needed.
  • Confirmation of installation – Press Enter once you have read the screen.
  • Install type – Type in “server” without the quotes and press Enter.
  • Install location – Accept the default.
  • E-mail notification – Default is yes, select if you want e-mail alerts. If you select yes, you will be prompted for a valid e-mail address and mail server.
  • Integrity check – Default is yes. Select if you want the local system periodically checked for intrusions.
  • Root kit detection – Default is yes. Good option since we need to maintain a high level of integrity on this system.
  • Active response – Default is yes. Select this option if you wish to be able to respond to events.
  • Firewall drop – Permits the OSSEC server to defend it self if a direct attack is detected.
  • White list – This will permit you to add IP addresses from which possible attacks will be ignored. Be careful with this option. If you will not have console access to the OSSEC server, it might be wise to identify one IP address that can always get in. Just ensure the source IP is a trustworthy system.
  • Enable Syslog – Default is yes. Select this option if you wish to collect logs from system that cannot run an OSSEC agent (like firewalls, switches, routers, access points, etc.).
  • Log files to be monitored – This screen identifies all of the local log files OSSEC will monitor. It is purely information, so all you can do is press Enter to move past it. If you notice one or more log files missing from the list, you can add them later to the ossec.conf file.

At this point OSSEC will access the local complier and install all needed files onto the system. Once complete, you can start the OSSEC server by executing the command:

/var/ossec/bin/ossec-control start

Defining OSSEC Agents

No se hacen con el servidor OSSEC todavía. Next, we need to pre-define any systems that will be running the OSSEC agent (client) software. This is performed using the manage_agents command. First however, we need to do a bit of homework. Make a list of all of the systems that will be running the OSSEC agent software. For each system, you will need a descriptive name as well as that system's IP address.

Now, execute the following from the command line:

/var/ossec/bin/manage_agents

This will produce the Agent Manager main menu. Press “A” followed by the Enter key to define your first system. Enter a descriptive name for the first system, followed by the system's IP address. Don't worry about the agent ID number. Simply accept the default and OSSEC will auto-assign the next available ID number. Once you confirm the information you entered, you will be returned to the Agent Manager main menu. Repeat the above process for each system that will be running an OSSEC agent.

Generating Keys

Once you have added in all of your systems, it is time to generate encryption keys. This step is also performed with the manage_agents utility. If you closed the tool after the last step, relaunch it now.

Press the “E” key followed by Enter to select the “Extract key for an agent” menu option. You will then be prompted for the ID number of the key you wish to extract. The descriptive names and IP addresses are listed with each ID number, so it should be trivial to identify which one you want. Start with the system you plan to install the agent software onto first.

OSSEC Agent Install On Linux

When installing the agent software on a Linux or UNIX client, you use the exact same Tar ball we used to install the server software. Run the same install script, but this time when you are prompted for the type of install you wish to perform, type in “agent” followed by the Enter key.

The client install has many of the same prompts as the server install. Use the info above to guide you through the process. The prompt that will vary however is that you will be asked to provide the IP address of the OSSEC server. Once complete, OSSEC will access the local complier and install all required files onto the system.

Next we need to import the Blowfish key from the OSSEC server. While still on the agent system, run the command:

/var/ossec/bin/manage_agents

When the Agent Manager menu appears, select “I” to import the Blowfish key.

When the next prompt appears, you need to manually enter the appropriate Blowfish key. Again, if you are running SSH to both systems at the same time, you can simply copy/paste between the two terminals. Make sure the key looks correct, press the Enter key, and then select “y” to confirm that the key looks correct. You will be returned to the Agent Manager menu. Select “q” in order to return to the command line.

Now we simply need to start the OSSEC agent. You can do so by executing the following command:

/var/ossec/bin/ossec-control start

You should see all of the OSSEC agent components start up, followed by a “Completed” message.

OSSEC Agent Install On Windows

OSSEC has a self-extracting executable that will permit you to install the agent software on a Windows system. Simply double click the executable to start the install process. You will be prompted to agree to the license as well as which components you wish to install. Simply follow the prompts till the OSSEC Agent Manager window appears.

The OSSEC Agent Manager window will prompt you for the IP address of the OSSEC server. It will also prompt you for the Blowfish key value to use, so extract the appropriate key on the server and enter the value in this field. Make sure you delete the prompt within this field before you paste in the Blowfish key. Otherwise communication with the server may fail.

Next, select “Manage” from the OSSEC Agent Manager menu, followed by “Start OSSEC”. You should now see the “Status:” indicator change to “Running…”.

Testing OSSEC

Once you have the server and agent software installed, started and the appropriate keys configured, it is now time to check our setup. Execute the following command on the OSSEC server:

cd /var/ossec/logs

And check out the ossec.log file:

less ossec.log

Check the log file for any errors. A common error is that OSSEC reports it cannot send e-mail. Make sure the mail server is running and that it is accepting connections. Once you are happy with the server setup, it is now time to check out the agents. Move down to the “alerts” directory:

cd alerts

And check out the alerts.log file:

less alerts.log

Specifically, you are looking for entries similar to the following:

2010 Feb 17 16:09:16 (desktop) 192.168.1.10->ossec

Rule: 501 (level 3) -> 'New ossec agent connected.'

Src IP: (none)

User: (none)

ossec: Agent started: 'test_system->192.168.1.10′.

You should see an entry for every system on which you installed the agent software.

Aún hay más

¡Menos mal! That's more than enough for one post! In my next post I'll get into leveraging Logwatch to parse all of the alert information being generated by OSSEC.

La combinación de Logwatch y OSSEC - Parte 2

February 16th, 2010 by Chris No comments »

In my last post I described how Logwatch could be used to simplify the log review process. In this post we'll look at OSSEC and what it brings to the table.

What Is OSSEC?

OSSEC , short for “Open Source SECurity”, is a host based intrusion detection system (HIDS). In other words, it is designed to detect attacks or policy violations if and when they occur. While it does not have the ability to protect against unknown or 0-Day attacks (that would be host based intrusion prevention), it does include a wide range of tools which can help you identify an intrusion when it occurs, as well as the extent of the damage that has been caused.

Plataformas compatibles

To take advantage of all of the features OSSEC has to offer, you have to run an agent on the system being protected. OSSEC agents can run on Windows, Mac OS X, Linux, and a wide range of UNIX systems. If you are just interested in the log analysis portion however, an even wider range of systems can be supported. This includes hardware from both Cisco and Juniper. A number of specific products are also supported like Checkpoint firewalls, Symantec Anti-Virus, Snort, Squid, and Arpwatch, just to name a few.

When you install OSSEC you have two configuration options, local or client/server. A local install is used when you need to run everything on a single system. The client/server installation lets you run a distributed environment protecting multiple systems at the same time. While most deployments are client/server based, if you want to give OSSEC a spin you can easily run everything on a single test system using a local install.

Análisis de registro

OSSEC includes a Log-based Intrusion Detection System (LIDS). This has the ability to review log files in near real time, while scrutinizing them for known attack patterns. When a log is generated on a protected system, the agent takes care of securely transmitting the log (Blowfish encryption using a pre-shared secret) back to the server. The server then takes care of performing the analysis.

Most log analysis tools process their rules in a linear format. By that I mean if we have 500 rules, rule one is checked, then rule two, then rule three and so on till a match is found or we reach the end of the rule set.  OSSEC works a bit differently as it implements a hieratical structure to the rules. Log entries are first classified and then checked only against whichever rules are appropriate. The result is that rather than needing to process all 500 rules, most events will get checked against 10 rules or less. This dramatically reduces the amount of overhead required to process the rule set.

Integrity Checking

OSSEC includes a tool called Syscheck for performing file and directory integrity checking. If you are running a Windows agent, you can also include specific keys within the Windows registry to be monitored as well. File changes can be detected using both MD-5 and SHA-1 hash algorithms. The system is extremely customizable. You can include or exclude single files, or entire directory structures. You can even set a flag to detect new file creation.

The agent software is designed to use a minimal amount of CPU during the integrity check. While this means the check will take longer, it also helps to minimize the performance hit to the system. Hash information is transmitted back to the server. The server then takes care of performing the hash comparison to see if any of the system's critical files have been changed. The server also stores a copy of the integrity check policy, so that if policy changes are made on the agent, they can be detected and reported as well.

Detección de anomalías

OSSEC goes far beyond log checking to verify system integrity. Usage policies can be centrally managed from the server, and then pushed out to the appropriate agents. For example you could define a policy regarding which Windows applications are acceptable (Office, Firefox, etc.) and which ones are not (IM client, Skype, etc.). You can even define acceptable configuration options like verifying that NT hashes are being used for password stored but not LanMan hashes.

OSSEC includes a number of other goodies in order to help verify a system's integrity. For example OSSEC has the ability to execute commands from the agent and monitor the output that gets generated. For example you could have the Linux agent execute the “df” command at regular intervals and generate an alert if disk usage exceeds 90%. A Windows example may be to have OSSEC generate an alert whenever file information is written to the alternate data streams area of NTFS.

Active Response

Finally, OSSEC includes the ability to respond when suspicious activity is detected. Responses can be generated from the server or the agent, which ever you specify. Responses can be as benign as generating an e-mail alert, to being as proactive as blocking a remote IP address for a limited amount of time. There are a number of included active response scripts you can draw on, or you can easily write your own.

Secure Architecture

The OSSEC authors have gone to great lengths to secure all of the components within the product. Tasks such as integrity checking are performed on the server, rather than the agent, so the trustworthiness of the hashes cannot be compromised during an attack. Processes are run with the lowest level of permissions possible, and different accounts are used to run each OSSEC component. This means that a compromise of a single application within OSSEC will not immediately lead to a compromise of the full package. Further, most components are run within a chrooted jail so their access to the system is even further restricted.

Palabras Finales

While OSSEC is a powerful tool, it is important to remember that it is a HIDS and not a log management solution. OSSEC can review log entries looking for suspicious patterns, but it will only save alert information. So while OSSEC will not replace your Security Information Management (SIM) solution, it can most certainly augment it. You can easily setup OSSEC to forward all alerts it generates to a central logging server .

While OSSEC is open source software, Trend Micro is primarily developing it. If you need commercial support, you can purchase a support contract through them at a reasonable fee.

Aún hay más

In my next installment we'll look at installing OSSEC and Logwatch. After that, we'll move into integrating the two together.

La combinación de Logwatch y OSSEC

February 15th, 2010 by Chris No comments »

I recently had a student ask me a question regarding the integration of Logwatch with OSSEC. I felt like this was a complex and yet cool enough idea that it warranted a series of posts to cover it in full. So over the next few days I'll talk about each of these tools, how to integrate them together, as well as what additional security visibility can be gained once the process is complete.

What Is Logwatch?

Logwatch is an excellent open source tool for generating daily human readable log reports. Log entries tend to fall into one of three categories:

  • Stuff you know is evil
  • Stuff you know is normal and can be safely ignored
  • Todo lo demás

It is that “everything else” category where Logwatch really shines. For the stuff we know is evil, we will setup some form of alerting system. For example we may write an alert signature that warns the security analyst when an account is being brute forced. But what about the attacks we don't know about or are not sure what they look like? This would be a clear example of that “everything else” category. The traffic is not normal, but we have not seen it before to have a signature waiting to generate an alert. Since we will be unable to catch the attack in real time, we will need to catch it during a daily log review.

Of course the problem with doing daily log reviews is that it is tedious and time consuming. I mean let's be honest, who really wants to spend their day reviewing one million plus log entries? Even if you did, are you sure you would actually catch the out of the ordinary traffic?

¿Cómo funciona?

What Logwatch does very well is permit you to reorganize your data into a format that is easier for humans to follow. Its real strength is that it permits you to move the stuff you understand out of the way (normal or evil), so that the unexpected log entries stand out like a sore thumb. In other words, Logwatch lets you summarize your log entries so the unusual stuff is easier to spot.

What I really love about Logwatch is that you don't lose anything. Many log review tools will only show you the stuff that has been pre-defined as being evil. The problem they all share is that when something evil but unexpected happens, it flies right under the wire. Because Logwatch lets you see everything, you no longer miss the unexpected.

Logwatch In Action

Lets discuss how Logwatch works using the SSH server service as an example. The scripts to deal with SSH have already been defined within Logwatch, so you do not need to do any tweaking to receive the features we are going to discuss.

When reviewing a log file, the first thing Logwatch does is reorganize log entries based on their message types. For example all Successful SSH logons are grouped together, as well as too many logon failures, refused connections, locked accounts, accounts without a proper shell, protocol mis-matches, etc. etc. etc. Once all the SSH messages are grouped by their type, the data is then summarized to reduce the amount of information being reported.

For example, the default is to summarize failed logon attempts by account and source IP. So a typical failed logon report section might look like this:

Failed logins from these:

bsmith/password from 1.2.3.4: 637 time(s)

jsmith/password from 1.2.3.5: 2 time(s)

So rather than having to review 639 log entries reporting a bad logon attempt, we have all the pertinent information summarized into three lines (if you include the title). Continue this process for all of the other SSH messages, and we have dramatically reduced the amount of time required to review our logs.

But what if something happens that Logwatch is not pre-programmed to recognize? When an unexpected log entry is found, Logwatch adds a section to the end of the service report called “Unmatched Entries”. So if we see this title in the SSH server section, we know some event has occurred that is either abnormal or unexpected for the SSH service. This could very well be some form of attack that we are not aware is making the rounds.

By focusing in on the unmatched entries section, we can quickly identify unexpected activity. As I stated earlier, this is really the main goal of doing daily log reviews. To find the stuff we don't expect which will sneak past our alerting system. Logwatch makes this process as quick and as painless as possible.

Resumen de características

In the above example I talked about doing daily log reviews, but to be honest Logwatch is highly customizable. You can specify any range you wish to use down to an interval of one second. For example let's say I'm investigating an intrusion rather than performing a daily log review. I could specify a range such as “2010/02/14 17:05:00 for that hour” to focus right in on the information that interest me. I can also focus in on one specific log file or service.

The detail level of the report is also customizable. Typically when you deal with security you get in the habit of always wanting the highest detail level of reporting. To be honest, with Logwatch a high level of detail is probably more than you will ever need. Personally I typically stick with “med” for medium and that works out nicely. You can also specify the reporting level as “low” or “high” or use a numeric range of 0-10 for a higher level of granularity (low =0, med=5, high=10).

Logwatch can be run automatically or as a manual process. Typically you will want to set it up to run automatically each day and summarize one day's worth of log entries. If you ever need to expand or focus the report, you can always run Logwatch from the command line while specifying exactly what you want to see. You can then use the “–save” option to specify a report name and directory location for storage.

Aún hay más

The above should give you a good idea as to the features Logwatch can bring to the table. In the next post I'll discuss OSSEC in the same level of detail. After that, I'll get into how to install each tool as well as how to integrate them together.

Día 2 de Keynote

January 12th, 2010 by Chris No comments »

Thanks to all who came out to the Encryption/DLP summit. Here are the slides from my keynote on day 2.

encryption-dlp-keynote