Archive for the 'registro' categoría

La combinación de Logwatch y OSSEC - Parte 4

18 de febrero 2010

En mi último post instalamos Logwatch así como OSSEC. Ahora es el momento para obtener Logwatch y OSSEC jugando juntos en el mismo entorno limitado. 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 configurar esto:

  1. Han Logwatch analizar los registros OSSEC directamente.
  2. Han OSSEC enviar sus alertas a un servidor de tipo Syslog, a continuación, ejecute Logwatch en el servidor syslog.

El beneficio para la opción # 1 es que sólo tenemos un sistema. Logwatch se llevará a cabo en el sistema que aloja el servidor OSSEC. El problema que se va a ejecutar en el embargo implica el archivo de alerta OSSEC. Las entradas de registro no se normaliza. Esto significa que el formato puede cambiar a partir de la entrada a entrada, e incluso puede extenderse en varias líneas. Va a ser una verdadera pesadilla para crear un script 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 que el servidor OSSEC aceptar entradas de registro de no-agente, tiene que escuchar en UDP/514. Este puerto es el mismo utilizado por un servidor de registro centralizado, y no se puede tener dos aplicaciones comparten el mismo puerto (excepto con Windows, pero el acceso es muy complicado socket). En el lado positivo, las entradas de alerta se normalizan cuando se transmite al servidor Syslog para la creación de un guión resumen Logwatch será mucho más fácil. Además, Logwatch ya sabe acerca de los archivos Syslog estándar, así que vamos a tener menos trabajo de personalización que hacer.

Finalmente, he mencionado 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 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. Con eso dicho, de hecho voy a cubrir la opción # 1, ya que es una instalación mucho más compleja.

Lidiando con fecha / hora

Echa un vistazo a el archivo de registro OSSEC principal y usted debe ver similar a lo siguiente:

[Root @ Fubar registros] # tail -3 / var / ossec / logs / ossec.log

02/18/2010 12:32:05 ossec-rootcheck: INFO: Poner fin a escanear rootcheck.

02/18/2010 14:27:06 ossec-syscheckd: INFO: A partir syscheck exploración.

02/18/2010 14:39:21 ossec-syscheckd: INFO: Hasta syscheck exploración.

Tenga en cuenta la forma en que se formateó el sello de fecha / hora. Esto es diferente a la mayoría de las aplicaciones, así que lo primero que tendremos que hacer es decirle a Logwatch cómo lidiar con este formato. Tendremos que crear un script que se puede llamar cuando se necesita que leen el formato se muestra arriba.

Para empezar, entrando en el directorio de scripts compartidos:

cd / usr / share / logwatch / scripts / compartidos

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

vi applylongdate

Esto es lo que necesita 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 /% H% d:% M:% S ');

if ($ Depurar> 5) {

print STDERR "DEBUG: ApplyLongDate interior ... \ n";

print STDERR "DEBUG: Buscando a:". $ SearchDate. "\ N";

}

mientras que (defined ($ ThisLine = <STDIN>)) {

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

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

print $ ThisLine;

}

}

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

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

chmod 755 applylongdate

Configurar los archivos de registro

A continuación tenemos que decir Logwatch en los archivos de registro OSSEC se encuentran. Cada vez que añada nuevos ficheros de registro o crear nuevos servicios para controlar en Logwatch, debe colocar los 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 encargará de alertas y cambios OSSEC respuesta activa.

Vamos a empezar con la creación del archivo de configuración para el archivo de registro principal OSSEC:

cd / etc / logwatch / conf / archivos de registro

vi ossec.conf

El contenido del archivo debe ser la siguiente manera:

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 la siguiente manera:

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

LogFile = / var / ossec / logs / 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 los servicios OSSEC

A continuación, tenemos que definir los servicios OSSEC e identificar lo que queremos usar como un título cuando los informes se generan. Así es como para crear el primer archivo:

cd / etc / logwatch / conf / servicios

vi ossec.conf

El contenido de este archivo es muy simple:

Title = "OSSEC Mensajes"

LogFile = ossec

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

vi ossec-alert.conf

El contenido de este archivo debe ser:

Title = "OSSEC alertas"

LogFile = ossec de alerta

Una vez terminado, guardar y salir como de costumbre.

El análisis de los comentarios

A continuación, tenemos que decirle 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 comenzar con un Logwatch suministrado script de prueba, sólo para asegurarse de que todo.

Empiece moviendo en el directorio correspondiente:

cd / etc / logwatch / scripts / servicios

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

vi ossec

El contenido de la escritura debe ser la siguiente manera:

#! / Bin / bash

# Este es el argumento de tan agradable que le mostrará las líneas que se

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

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

# Volcar de vuelta a STDOUT.

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

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

echo "Fecha Entre: $ LOGWATCH_DATE_RANGE"

echo "Nivel de detalle: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "nivel de depuración: $ LOGWATCH_DEBUG"

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

gato

Cree su segundo guión:

vi ossec de alerta

e incluyen el mismo contenido exacto:

#! / Bin / bash

# Este es el argumento de tan agradable que le mostrará las líneas que se

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

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

# Volcar de vuelta a STDOUT.

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

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

echo "Fecha Entre: $ LOGWATCH_DATE_RANGE"

echo "Nivel de detalle: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "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 | less

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

logwatch servicio ossec | less

logwatch servicio ossec alerta | less

Una mayor personalización

Una vez que llegue a todos los que trabajan más arriba, usted puede centrarse en conseguir Logwatch para filtrar y resumir las entradas del registro. Logwatch es bastante flexible, y se puede personalizar la salida de la forma que desee. Una de las cosas buenas de la escritura de la 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 puede resumir las entradas según considere oportuno. Para algunas ideas, puedes ver los archivos que se encuentran en:

/ Usr / share / logwatch / scripts / servicios

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

A medida que desarrolla sus guiones, prestar mucha atención a los $ LOGWATCH_DETAIL_LEVEL "variable. Esto le permitirá personalizar el nivel de salida del informe en función de 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 comando siguiente:

menos sshd

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

/ Detalle <Introducir clave>

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 se pulsa Intro la búsqueda saltar a través del archivo hasta que encuentra la primera instancia de la cadena de texto. También se hará hincapié en la cadena de búsqueda. En el primer partido se dará cuenta de que el autor asigna a la variable "$ detalle" a 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 de nuevo seguido de la tecla Enter. Esto salta a través del archivo a la siguiente instancia de "Detalle". Usted debe ver:

if ($ Detalle> = 20) {

$ Usuarios {$ usuario} {$ host} {$ Método} + +;

} Else {

if ($ host ~ / $ IgnoreHost /) {

$ Usuarios {$ usuario} {} {$ host "(todos los )"}++;

Tenga en cuenta que el autor ofrece más información si el nivel de detalle se establece en 20 (a medio camino entre baja y media) o superior. Seguir saltando a través del archivo y verás otros ejemplos donde el autor aprovechado esta técnica.

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

if (otralista llaves%) {

print "\ n ** Las entradas sin igual ** \ n";

print "$ _: $ otralista {$ _} tiempo (s) \ n" foreach otralista% teclas;

}

Esta sección es muy importante, ya que es un cajón de sastre final. Pensar en una política 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 ocurre algo inesperado, así es como quiero que manejar la situación.

La afirmación anterior tiene el mismo propósito al analizar el archivo de registro. Todas las anteriores declaraciones "if" intentar igualar una cadena de texto en la entrada del 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, se imprima en una sección titulada" ** ** Las entradas sin igual ". Este paso es muy importante porque sin ella nunca vamos a ver las entradas inesperadas. Se trata de las entradas inesperadas que son probablemente los más importantes y más interesantes.

Resumen ejecutivo

Ambos OSSEC y Logwatch son excelentes herramientas complementarias. OSSEC destaca en la advertencia de que cuando un patrón de ataque conocido se lleva a cabo. Logwatch es un magnífico instrumento para resumir una parte de los registros de tiempo para que los humanos pueden realmente entender lo que está pasando. Mediante la combinación de las dos herramientas que pueden crear una defensa mucho más sólida en profundidad la postura. El conjunto es mayor que la suma de las partes.

La combinación de Logwatch y OSSEC - Parte 3

17 de febrero 2010

En mis dos últimos posts hablé Logwatch y OSSEC, así como la forma en que se puede aprovechar para aumentar su nivel de seguridad. En esta entrega voy a hablar de 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 que usted ya tenga una copia en el sistema. Para comprobarlo, de inicio de sesión como root e intente ejecutar Logwatch con la opción "-v" switch. Si ve:

[Root @ Fubar logwatch] # logwatch-v

Logwatch 7.3.6 (liberada 05/19/07)

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

Hay tres sabores de Logwatch que se puede descargar, en formato RPM binarios, fuentes en formato RPM, o la fuente en una bola de alquitrán. Si su sistema es compatible con 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:

rpm-U-7.3.6-logwatch 1.noarch.rpm

No olvide que usted puede utilizar la tecla de tabulación para auto-completar el nombre del archivo en lugar de tener que escribir toda la cosa.

Instalación Logwatch De Fuente

Instalación de la fuente es un poco más lento. Recuerde que para poder instalar el código fuente ya debe tener un compilador (como gcc) instalado en su sistema. De 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

Usted verá una estructura de directorios por debajo de su ubicación actual y se crean gran cantidad de archivos que se copian pulg Ahora tenemos que entrar en el directorio superior que fue creada:

cd logwatch-7.3.6

Con el fin de Logwatch para correr, hay un montón de directorios que se deben crear en el sistema. Estos se encuentran documentados en el archivo README en el directorio actual. Por suerte, Logwatch incluye un script de instalación que puede hacer todo el trabajo por usted. Por desgracia, el guión tiene los permisos mal set para que no se ejecuta por defecto. Esto es bastante fácil de solucionar sin embargo 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 Logwatch, ejecutar el comando:

logwatch | less

Verá la pantalla del terminal se queda en blanco, pero eso es normal. Es muy probable que vea un informe Logwatch se muestra en 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 que el informe muestre 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, tienes dos opciones de instalación con OSSEC, local o cliente / servidor. En este post me voy a centrar en la estructura de cliente / servidor, ya que es un poco más complejo. Si usted está realizando una instalación local, sólo tiene que seleccionar el "local" durante el proceso de instalación y omitir la sección sobre la configuración de un canal seguro entre el agente y el servidor.

Iniciar con el servidor

OSSEC utiliza el cifrado Blowfish para asegurar la comunicación entre el cliente y el servidor. Blowfish es la clave simétrica basado, por lo que ambas partes deben saber cuál es el valor clave para el uso con el fin de comunicarse. El servidor es responsable de generar la clave simétrica, por lo que tiene que instalar primero el software del servidor. Durante la instalación del cliente que se le solicitará un valor clave así que obviamente tendrá que tener esa mano antes de tiempo.

He aquí un consejo para ahorrar tiempo. El valor de la clave es larga y casi imposible de recordar. La manera más fácil para mover el valor de la clave del sistema de servidor para el sistema de agentes es el uso de SSH. Crear una conexión segura con el servidor OSSEC, y el extracto de la tecla correspondiente (direcciones más abajo). En una ventana de terminal en segundo lugar, crear una sesión SSH al sistema en el que va a instalar el agente. Cuando la instalación del cliente que solicita el valor de la clave, sólo tiene que copiar / pegar entre las dos terminales.

Instalación del servidor OSSEC

El software del servidor está disponible como una bola de alquitrán, por lo que puede hacerse con una copia de la última versión de la página de descarga OSSEC . A continuación, tendrá que extraer el contenido de la bola de alquitrán:

tar xvzf ossec-HIDS-2.3.tar.gz

A continuación, pasar a la estructura del directorio que acaba de crear:

cd ossec-HIDS-2.3

OSSEC proporciona un script de instalación que le guiará por el proceso de instalación del servidor. Para ejecutar el script, escriba:

. / Install.sh

No te olvides el punto al principio del comando. Ahora se le pedirá a través de una serie de opciones de instalación:

  • Idioma - El valor por defecto es el Inglés. Cambios que considere oportunos.
  • La confirmación de la instalación - Pulse Intro una vez que haya leído la pantalla.
  • Tipo de instalación - Escriba "servidor" sin las comillas y pulse Intro.
  • Ubicación de instalación - Acepte el valor predeterminado.
  • Notificación por correo electrónico - no está en sí, seleccione si desea alertas por correo electrónico. Si selecciona Sí, se le pedirá una válida dirección de correo electrónico y servidor de correo.
  • Comprobación de la integridad - no está en sí. Seleccione si desea que el sistema local de control periódico de las intrusiones.
  • Detección de rootkit - Por defecto es sí. Buena opción ya que necesitamos mantener un alto nivel de integridad en el sistema.
  • Respuesta activa - Por defecto es sí. Seleccione esta opción si desea ser capaz de responder a los eventos.
  • Caída de servidor de seguridad - Permite al servidor OSSEC para defender lo mismo si un ataque directo que se detecte.
  • Lista blanca - Esto le permitirá añadir las direcciones IP de los posibles ataques que se tendrá en cuenta. Tenga cuidado con esta opción. Si usted no tiene acceso a la consola con el servidor OSSEC, podría ser prudente para identificar una dirección IP que siempre se puede entrar sólo garantizar la IP de origen es un sistema confiable.
  • Habilitar Syslog - Por defecto es sí. Seleccione esta opción si desea recopilar registros del sistema que no puede ejecutar un agente OSSEC (como firewalls, switches, routers, puntos de acceso, etc.)
  • Los archivos de registro para ser monitoreados - Esta pantalla identifica todos los archivos de registro local OSSEC supervisará. Es pura información, todo lo que puede hacer es presionar Enter para mover pasado. Si usted nota uno o más archivos de registro que faltan de la lista, puede agregar más adelante en el fichero de ossec.conf.

En este punto OSSEC tendrán acceso a los locales compilador e instalar todos los archivos necesarios en el sistema. Una vez completado, puede iniciar el servidor OSSEC ejecutando el comando:

/ Var / ossec / bin / ossec-control de arranque

Agentes de la definición de OSSEC

No hemos terminado con el servidor OSSEC todavía. A continuación, tenemos que pre-definir cualquier sistema que se ejecuta el agente OSSEC (cliente) de software. Esto se realiza mediante el comando manage_agents. Primero, sin embargo, que tenemos que hacer un poco de tarea. Haga una lista de todos los sistemas que va a ejecutar el software del agente OSSEC. Para cada sistema, usted necesitará un nombre descriptivo, así como la dirección IP de ese sistema.

Ahora, ejecute lo siguiente desde la línea de comandos:

/ Var / ossec / bin / manage_agents

Esto producirá el menú del Gestor de agentes principales. Presione "A", seguido de la tecla Intro para definir el sistema en primer lugar. Escriba un nombre descriptivo para el sistema en primer lugar, seguido de la dirección IP del sistema. No te preocupes por el número de identificación del agente. Simplemente aceptar el valor predeterminado y OSSEC se auto-asigna el siguiente número de identificación disponibles. Una vez confirmada la información introducida, se le devuelve al menú principal del Administrador de agentes. Repita el proceso anterior para cada sistema que se está ejecutando un agente OSSEC.

Generar claves

Una vez que haya añadido en todos sus sistemas, es hora de generar claves de cifrado. Este paso también se realiza con la utilidad manage_agents. Si ha cerrado la herramienta después de la última etapa, que relanzar ahora.

Pulse la tecla "E" seguido de Enter para seleccionar la opción "Extraer clave para un agente" del menú. A continuación se le pedirá el número de ID de la clave que desea extraer. Los nombres descriptivos y las direcciones IP se muestran con cada número de identificación, por lo que debería ser trivial para identificar cuál de ellos desea. Empiece con el sistema va a instalar el software del agente en primera.

OSSEC Agente de la instalación a Linux

Al instalar el software del agente en un cliente Linux o UNIX, se utiliza el balón exactamente Tar misma que utilizó para instalar el software de servidor. Ejecute el script de instalación misma, pero esta vez cuando se le pregunte por el tipo de instalación que desea realizar, el tipo de "agente", seguido de la tecla Enter.

La instalación del cliente tiene muchas de las mismas indicaciones que la instalación del servidor. Utilice la información anterior que le guiará durante el proceso. El mensaje que puede variar sin embargo, es que se le pedirá proporcionar la dirección IP del servidor OSSEC. Una vez terminado, tendrá acceso a OSSEC el compilador locales e instalar todos los archivos necesarios en el sistema.

A continuación tenemos que importar la clave del servidor Blowfish OSSEC. Aunque todavía en el sistema de agente, ejecute el comando:

/ Var / ossec / bin / manage_agents

Cuando aparezca el menú del Gestor de agentes aparece, seleccione "I" para importar la clave Blowfish.

Cuando aparezca el mensaje siguiente aparece, tendrá que introducir manualmente la clave apropiada Blowfish. Una vez más, si está ejecutando SSH en ambos sistemas al mismo tiempo, sólo tiene que copiar / pegar entre las dos terminales. Asegúrese de que la clave es correcta, pulse la tecla Enter, y luego seleccione "y" para confirmar que la clave es correcta. Volverá al menú del Gestor de agentes. Seleccione "q" para volver a la línea de comandos.

Ahora simplemente tenemos que iniciar el agente OSSEC. Puede hacerlo ejecutando el siguiente comando:

/ Var / ossec / bin / ossec-control de arranque

Usted debe ver a todos los componentes del agente OSSEC puesta en marcha, seguido de un mensaje "COMPLETADO".

OSSEC Agente de la instalación en Windows

OSSEC tiene un ejecutable de extracción automática que le permitirá instalar el software del agente en un sistema Windows. Simplemente haga doble clic en el ejecutable para iniciar el proceso de instalación. Se le solicita que acepte la licencia, así como los componentes que desea instalar. Simplemente siga las instrucciones hasta que el agente OSSEC Aparece la ventana Administrador.

El Agente de OSSEC ventana del Administrador le pedirá la dirección IP del servidor OSSEC. También le preguntará por el valor de la clave Blowfish de utilizar, para extraer la clave adecuada en el servidor e introduzca el valor en este campo. Asegúrese de eliminar el mensaje dentro de este campo antes de pegar en la clave de Blowfish. De lo contrario la comunicación con el servidor puede fallar.

A continuación, seleccione "Administrar" en el menú Agente Administrador OSSEC, seguido de "Start OSSEC". Ahora debería ver el "Status:" Indicador de cambio de "Ejecución de ...".

Pruebas OSSEC

Una vez que tenga el servidor y el software agente instalado, iniciado y las teclas correspondientes, configurado, ahora es tiempo para comprobar nuestra configuración. Ejecute el siguiente comando en el servidor OSSEC:

cd / var / ossec / logs

Y echa un vistazo al archivo ossec.log:

menos ossec.log

Revise el archivo de registro de los errores. Un error común es que los informes OSSEC no puede enviar e-mail. Asegúrese de que el servidor de correo está funcionando y que está aceptando conexiones. Una vez que esté satisfecho con la configuración del servidor, ahora es el momento de revisar los agentes. Desplácese hacia abajo a los "alertas" del directorio:

cd alertas

Y echa un vistazo al archivo alerts.log:

menos alerts.log

En concreto, está en busca de entradas similar al siguiente:

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

Regla: 501 (nivel 3) -> "Nuevo agente ossec conectados.

IP src: (ninguno)

Usuario: (ninguno)

ossec: Agente de empezar: "test_system-> 192.168.1.10.

Usted debe ver una entrada para cada sistema en el que instaló el software del agente.

Más por venir

¡Menos mal! Eso es más que suficiente para un post! En mi próximo post voy a entrar en aprovechar Logwatch para analizar toda la información de alerta generada por OSSEC.

La combinación de Logwatch y OSSEC - Parte 2

16 de febrero 2010

En mi último post me describió cómo Logwatch podrían ser utilizados para simplificar el proceso de revisión del registro. En este post vamos a ver OSSEC y lo que trae a la mesa.

¿Qué es OSSEC?

OSSEC , abreviatura de "seguridad de código abierto", es una serie basada en el sistema de detección de intrusos (HIDS). En otras palabras, está diseñado para detectar ataques o violaciónes de política, siempre y cuando se producen. Si bien no tiene la capacidad de proteger frente a ataques desconocidos o de día 0 (que sería la prevención de intrusiones basado), que incluye una amplia gama de herramientas que pueden ayudarle a identificar una intrusión cuando se produce, así como el alcance de la de los daños que ha causado.

Plataformas compatibles

Para tomar ventaja de todas las características OSSEC tiene para ofrecer, usted tiene que ejecutar un agente en el sistema se está protegiendo. Agentes OSSEC puede ejecutar en Windows, Mac OS X, Linux, y una amplia gama de sistemas UNIX. Si está interesado solamente en la parte de análisis de registros sin embargo, una gama más amplia de sistemas pueden ser compatibles. Esto incluye el hardware de Cisco y Juniper. Una serie de productos específicos también son compatibles, como firewalls Checkpoint, Symantec Anti-Virus, Snort, Squid, y Arpwatch, sólo para nombrar unos pocos.

Al instalar OSSEC usted tiene dos opciones de configuración, local o cliente / servidor. Una instalación local se utiliza cuando se necesita para ejecutar todo en un solo sistema. La instalación de cliente / servidor permite ejecutar un entorno distribuido de proteger los sistemas múltiples a la vez. Aunque la mayoría de las implementaciones son cliente / servidor, si usted quiere dar un giro OSSEC que puede ejecutar todo en un sistema de prueba solo con una instalación local.

De análisis de registro

OSSEC incluye un sistema de intrusión basado en un registro de detección (tapas). Esto tiene la posibilidad de revisar los archivos de registro en tiempo real, mientras que para examinar los patrones de ataque conocidos. Cuando un registro se genera en un sistema protegido, el agente se encarga de transmitir de forma segura el registro (cifrado Blowfish con un secreto pre-compartida) de vuelta al servidor. Después, el servidor se encarga de realizar el análisis.

La mayoría de las herramientas de análisis de registro de proceso de sus reglas en un formato lineal. Con esto quiero decir, si tenemos 500 reglas, la regla uno es seleccionado, entonces la regla dos, entonces la regla de tres y así sucesivamente hasta que se encuentra una coincidencia o se llega al final del conjunto de reglas. OSSEC trabaja un poco diferente, ya que implementa una estructura hierática a las reglas. Las entradas del registro son los primeros clasificados y luego verificarán contra lo que las reglas son las adecuadas. El resultado es que en lugar de tener que procesar todas las 500 normas, la mayoría de los eventos que nos registramos en contra de las reglas 10 o menos. Esto reduce drásticamente la cantidad de carga necesaria para procesar el conjunto de reglas.

Comprobación de la integridad

OSSEC incluye una herramienta llamada Syscheck para llevar a cabo la comprobación de integridad de archivos y directorios. Si está ejecutando un agente de Windows, también puede incluir teclas específicas en el registro de Windows para ser controlados también. Cambios en los archivos pueden ser detectados utilizando MD-5 y SHA-1 hash de algoritmos. El sistema es extremadamente personalizable. Puede incluir o excluir archivos individuales, o estructuras enteras del directorio. Incluso se puede establecer un indicador para detectar la creación de archivos nuevos.

El software del agente está diseñado para utilizar una cantidad mínima de la CPU durante la comprobación de integridad. Si bien esto significa que el cheque se tomará más tiempo, sino que también ayuda a minimizar el impacto en el rendimiento del sistema. Información de hash se transmite de vuelta al servidor. Después, el servidor se encarga de realizar la comparación de hash para ver si alguno de los archivos críticos del sistema han cambiado. El servidor también almacena una copia de la política de control de integridad, de modo que si los cambios de política se hacen en el agente, que puede ser detectado y reportado también.

Detección de anomalías

OSSEC va mucho más allá de registro de control para verificar la integridad del sistema. Las políticas de uso se puede gestionar de forma centralizada desde el servidor, y luego se transfieren a los agentes adecuados. Por ejemplo, podría definir una política respecto de los cuales las aplicaciones de Windows son aceptables (Office, Firefox, etc) y cuáles no lo son (cliente de mensajería instantánea, Skype, etc.) Usted puede incluso definir las opciones de configuración como aceptable la verificación de que los hashes NT se utilizan para almacenar la contraseña pero no hashes LanMan.

OSSEC incluye un número de ventajas que otros con el fin de ayudar a verificar la integridad del sistema. Por ejemplo OSSEC tiene la capacidad para ejecutar comandos del agente y controlar la salida que se genera. Por ejemplo, usted podría tener el agente de Linux ejecutar el "df" mando a intervalos regulares y generar una alerta si el uso del disco excede el 90%. Un ejemplo de Windows puede tener OSSEC generar una alerta cada vez que información de los archivos se escriben en el flujos de datos alternativos área de NTFS.

Respuesta Activa

Por último, OSSEC incluye la capacidad de responder cuando se detecta actividad sospechosa. Las respuestas pueden ser generados por el servidor o el agente, lo que usted especifique. Las respuestas pueden ser tan benigna como la generación de una alerta por e-mail, de ser tan proactivos como el bloqueo de una dirección IP remota de una cantidad limitada de tiempo. Hay una serie de scripts incluidos respuesta activa se puede dibujar, o usted puede fácilmente escribir el suyo propio.

Arquitectura Segura

Los autores OSSEC han hecho grandes esfuerzos para asegurar que todos los componentes en el producto. Tareas como la comprobación de integridad se llevan a cabo en el servidor, en lugar del agente, por lo que la fiabilidad de los valores hash no puede verse comprometida durante un ataque. Los procesos se ejecutan con el nivel más bajo de permisos posibles, y las diferentes cuentas se utilizan para ejecutar cada componente OSSEC. Esto significa que un compromiso de una aplicación de un OSSEC no nos llevará a un compromiso de todo el paquete. Además, la mayoría de los componentes se ejecutan dentro de una cárcel chroot por lo que su acceso al sistema es aún más restringida.

Palabras finales

Mientras OSSEC es una poderosa herramienta, es importante recordar que se trata de un HIDS y no una solución de administración de registros. OSSEC puede revisar las entradas del registro en busca de patrones sospechosos, pero sólo se guarda la información de alerta. Así, mientras que OSSEC no sustituirá a la Gestión de Seguridad de la Información (SIM) en solución, que puede sin duda que aumentar. Puede configurar fácilmente OSSEC para desviar todas las alertas que genera a un servidor central de registro .

Mientras OSSEC es un software de código abierto, Trend Micro es principalmente su desarrollo. Si necesita soporte comercial, usted puede comprar un contrato de asistencia técnica a través de ellos a un precio razonable.

Más por venir

En mi próxima entrega veremos la instalación de OSSEC y Logwatch. Después de eso, vamos a pasar a la integración de los dos juntos.

La combinación de Logwatch y OSSEC

15 de febrero 2010

Hace poco tuve un alumno me pregunta una pregunta acerca de la integración de Logwatch con OSSEC. Me sentí como que era una idea bastante compleja y aún fresco que garantiza una serie de puestos para cubrir en su totalidad. De modo que en los próximos días voy a hablar de cada una de estas herramientas, cómo integrarlos en conjunto, así como lo que la visibilidad de seguridad adicional se puede obtener una vez que se complete el proceso.

¿Qué es Logwatch?

Logwatch es una excelente herramienta de código abierto para la generación de reportes diarios de registro legible por humanos. Las entradas de registro tienden a caer en una de tres categorías:

  • Cosas que sabes que es malo
  • Cosas que sabes que es normal y puede ser ignorado
  • Todo lo demás

Se trata de que "todo lo demás", categoría en la que Logwatch realmente brilla. Por las cosas que sabemos que es malo, vamos a configurar algún tipo de sistema de alerta. Por ejemplo, podemos escribir una firma de alerta que advierte el analista de seguridad cuando una cuenta es que a fuerza bruta. Pero ¿qué pasa con los ataques que no conocen o no están seguros de lo que parecen? Esto sería un claro ejemplo de que "todo lo demás" categoría. El tráfico no es normal, pero no lo hemos visto antes de tener una firma a la espera de generar una alerta. Ya que no será capaz de atrapar el ataque en tiempo real, que tendrá que tomar durante una revisión del registro de todos los días.

Por supuesto, el problema de hacer revisiones diarias de registro es que es tedioso y lento. Quiero decir, seamos sinceros, que realmente quiere pasar sus días revisando millón más entradas de registro? Incluso si lo hiciera, ¿estás seguro que realmente captura el tráfico de la corriente?

¿Cómo funciona?

¿Qué Logwatch hace muy bien es permitirle a reorganizar sus datos en un formato que es más fácil para los seres humanos a seguir. Su verdadera fuerza es que le permite mover las cosas que entiendo de la forma (normal o para mal), de modo que las entradas del registro inesperado se destacan como un pulgar dolorido. En otras palabras, Logwatch le permite resumir las entradas de registro para que el material extraño es fácil de detectar.

Lo que realmente me gusta de Logwatch es que no se pierde nada. Muchas herramientas de revisión del registro sólo le mostrará las cosas que ha sido pre-definido como el mal. El problema que todos compartimos es que cuando algo malo, pero sucede lo inesperado, vuela justo debajo del alambre. Porque Logwatch le permite ver todo, ya no te pierdas lo inesperado.

Logwatch En Acción

Vamos a discutir cómo Logwatch funciona con el SSH servicio de servidor como un ejemplo. Las secuencias de comandos para hacer frente a SSH ya se han definido dentro de Logwatch, por lo que no es necesario hacer ningún ajuste para recibir las características que vamos a discutir.

Al revisar un archivo de registro, el Logwatch Lo primero que hace es reorganizar las entradas de registro sobre la base de sus tipos de mensaje. Por ejemplo, todos los inicios de sesión SSH con éxito se agrupan, así como los fallos de inicio de sesión de más, se negó conexiones, las cuentas bloqueadas, cuentas sin una concha adecuada, el protocolo de desajustes, etc, etc, etc Una vez que todos los mensajes de SSH se agrupan por su tipo, los datos se resumen para reducir la cantidad de información que se informa.

Por ejemplo, el valor por defecto es un resumen de los intentos fallidos de inicio de sesión de cuenta y dirección IP de origen. Por lo que una típica sección no informe de inicio podría tener este aspecto:

Intentos fallidos de las siguientes:

BSmith / contraseña desde 1.2.3.4: 637 tiempo (s)

jsmith / contraseña de 1.2.3.5: 2 hora (s)

Así que en lugar de tener que revisar las entradas de registro de 639 informes de un intento de inicio de sesión malo, tenemos toda la información pertinente resumir en tres líneas (si se incluye el título). Continúe este proceso para todos los otros mensajes de SSH, y que han reducido drásticamente la cantidad de tiempo necesario para revisar nuestros registros.

Pero lo que si sucede algo que Logwatch no está pre-programado para reconocer? Cuando una entrada de registro inesperada se encuentra, Logwatch añade una sección al final del informe de servicio llamada "entradas sin igual". Así que si vemos este título en la sección del servidor SSH, sabemos que un evento ha ocurrido es que sea anormal o inesperado para el servicio SSH. Este bien podría ser algún tipo de ataque que no nos damos cuenta es hacer las rondas.

Al centrarse en la sección de entradas sin precedentes, que puede identificar rápidamente la actividad inesperada. Como he dicho antes, esto es realmente el objetivo principal de hacer revisiones diarias de registro. Para encontrar las cosas que no esperamos que colar a través de nuestro sistema de alerta. Logwatch hace este proceso tan rápido y sin dolor como sea posible.

Resumen de características

En el ejemplo anterior he hablado de hacer revisiones diarias de registro, pero para ser honesto Logwatch es altamente personalizable. Se puede especificar cualquier rango que desea utilizar hasta un intervalo de un segundo. Por ejemplo, digamos que estoy investigando una intrusión en lugar de realizar una revisión del registro de todos los días. Podría especificar un rango como "02/14/2010 17:05:00 para esa hora" para centrarse en el derecho a la información que me interesa. También puede centrarse en un archivo de registro o servicio específico.

El nivel de detalle del informe también se puede personalizar. Normalmente, cuando usted se ocupa de la seguridad que tenga el hábito de querer siempre el mayor nivel de detalle de la información. Para ser honesto, con Logwatch un alto nivel de detalle es probablemente más de lo que se necesita. Personalmente me suelen seguir con "medicina" para el medio y que funciona muy bien. También puede especificar el nivel de información como de "bajo" o "alto" o usar un rango numérico de 0 a 10 para un mayor nivel de granularidad (bajo = 0, med = 5, alto = 10).

Logwatch se puede ejecutar de forma automática o como un proceso manual. Normalmente, usted tendrá que configurarlo para que se ejecute automáticamente cada día y un resumen de un solo día de las entradas del registro. Si alguna vez necesidad de ampliar o centrar el informe, que puede siempre ejecutar Logwatch de la línea de comandos y especificar exactamente lo que quiere ver. A continuación, puede utilizar el "de ahorro" para especificar un nombre de informe y el directorio de almacenamiento.

Más por venir

Lo anterior debería darle una buena idea en cuanto a las características Logwatch puede llevar a la mesa. En el próximo post hablaré OSSEC en el mismo nivel de detalle. Después de eso, voy a entrar en cómo instalar cada herramienta, así como la forma de integrar entre sí.

Configurar un sistema de gestión de seguridad de la información-Parte 6

20 de agosto 2009

Hasta ahora, en esta serie hemos cubierto:

  • La definición de un alcance y enfoque de la tarjeta SIM
  • Importancia de la construcción en lugar de comprar su primer sistema de
  • La arquitectura y la planificación de la capacidad
  • Las fases de despliegue recomendado
  • Selección de una plataforma de servidor de registro centralizado
  • ¿Cómo aceptar las entradas de registro remoto
  • Instalación, la gravedad y la prioridad
  • Cómo ordenar los mensajes de registro
  • Configuración de aplicaciones y sistemas operativos para enviar las entradas de registro

Cool. Así que tenemos las entradas del registro de una serie de sistemas que se están recogidos en un servidor centralizado. Ahora viene la tarea más importante, aprovechar esa información. Las entradas de registro se pueden agrupar en dos categorías: los mensajes críticos que queremos saber acerca de inmediato, y entradas de registro que se quedan atrapados como parte de un proceso de revisión.

Lista negra vs. Lista blanca

Al revisar los mensajes de registro, tenemos dos posturas posibles que puede utilizar. La primera se conoce como listas negras. Con el método de listas negras que definir lo que hace que un evento lo suficientemente interesante como para justificar la presentación de informes. Esto es similar a cómo el software antivirus detecta el malware o el proceso que utilizamos para filtrar el spam.

Como la mayoría de las cosas en la vida, las listas negras tiene aspectos buenos y malos. En el lado positivo, por lo general es bastante fácil de escribir una firma, si sabemos lo que queremos buscar. Las firmas pueden definirse con precisión para ayudar a minimizar el número de falsos positivos que nos encontramos. El problema con la lista negra es que tenemos que saber lo que estamos buscando. Si un nuevo ataque genera una firma única que hemos encontrado nunca en el pasado, un sistema de listas negras, probablemente se perderá el evento porque no hay ninguna firma se ha definido.

Con listas blancas que definen los eventos que entender, a continuación, centrar nuestra atención en los mensajes de registro nuevos y únicos que se encuentran. En el lado positivo que son mucho más propensos a contraer cortar los ataques del borde. Lista blanca tiende a ser relativamente ruidoso sin embargo, ya que estamos destinados a encontrar mensajes únicos de registro que no son indicativos de un evento de seguridad.

Así que debemos usar? Buena defensa en profundidad las prácticas nos dicen que debemos usar ambos. ;)

Alerta en tiempo real

Podemos aprovechar para realizar las listas negras en tiempo real de alerta de evento que queremos estar al tanto de cuanto ocurre. Las listas negras sólo se debe utilizar para los tipos de bajo nivel de ruido de los acontecimientos. En otras palabras, queremos seguir con la escritura de firmas para los eventos que tienen una alta probabilidad de ser un problema de seguridad real. Buenos ejemplos son:

  • Diferentes fallos de inicio de sesión nombre de todos en la misma dirección IP en un corto período de tiempo
  • Múltiples errores HTTP 403 que se generan por una única dirección IP en un corto período de tiempo
  • Los sistemas internos que reciben muchos errores ICMP o TCP restablece en un corto período de tiempo

Para llevar a cabo en tiempo real de alertas, que necesita un software que hará un seguimiento de los registros en tiempo real. Las entradas del registro deberá cotejarse con las firmas definidas, lo cual también indica qué hacer cuando se produce el evento.

Swatch

Una de las mejores herramientas que puede utilizar para las entradas del registro de seguimiento es Swatch . Swatch se basa en Perl. Esto significa que, si bien está diseñado para sistemas UNIX y Linux, puede hacerlo funcionar en Windows si tiene instalado Perl. La simplicidad es la mayor fortaleza de los Swatch y la debilidad. Mientras que Swatch es relativamente fácil de implementar, también es algo limitada en su funcionalidad. Sin embargo, si usted es nuevo en el registro, Swatch hace una excelente herramienta para la primera alerta en tiempo real.

Para implementar Swatch, usted tendrá que crear un archivo de configuración única para cada archivo de registro que desea supervisar. En el archivo de configuración que le dirá a Swatch lo que debe buscar en el archivo de registro en particular, y qué hacer cuando se detecta el evento.

Por ejemplo, digamos que vamos a tener Swatch seguimiento de registro del servidor Web de error. Es posible que desee crear una entrada similar al siguiente en el archivo de configuración de Swatch para el registro de errores:

# Cuidado con desbordamientos de búfer

watchfor / cliente negado por la configuración del servidor | Nombre de archivo demasiado largo /

mail = noc@fubar.org: webmaster@fubar.org, subject = servidor Web desbordamiento intento

La línea que comienza con "#" es simplemente el comentario sobre la firma. La línea que identifica watchfor cadena de caracteres (s) que desea definir como interesante. En esta regla en particular se han definido dos cadenas diferentes, "cliente negado por la configuración del servidor" y "Nombre de archivo demasiado largo" lo más interesante. El carácter de barra vertical entre las cuerdas actúa como una lógica "o". Si cualquiera de cadena se encuentra, el parámetro de correo define dos diferentes direcciones de correo electrónico que deben ponerse en contacto. La línea de asunto del correo electrónico será "servidor Web intento de desbordamiento", mientras que el cuerpo del e-mail será la entrada del registro actual.

Si hay otros patrones que deseamos detectar, podríamos añadir watchfor adicionales y declaraciones de correo. Si queremos hacer algo más que enviar un e-mail, el parámetro exec puede ser utilizado para ejecutar cualquier aplicación se encuentra en el sistema local. El parámetro umbral también se puede utilizar para limitar la velocidad de la notificación de eventos.

Coordinador de eventos simples (SEC)

SEC es una increíble herramienta de alerta se puede descargar desde el sitio web principal . Es compatible con BSD y Linux, y viene con una serie de populares versiones de Linux. SEC es totalmente compatible con las expresiones regulares y le permite crear firmas muy granular.

El formato de la regla es como sigue:

= Tipo de método de detección

PTYPE = patrón tipo (expresión regular, coinciden con cadena)

= ¿Qué patrón de búsqueda de

desc = Descripción (puede ser una variable)

action = ¿Qué hacer cuando se detecta

Hay un excelente archivo de pre-escrito las reglas que usted puede utilizar que es bien vale la pena mirar. Puede hacer coincidir en varios patrones, definir umbrales múltiples, todas durante el procesamiento de cientos de mensajes de registro por segundo. Sobre el único inconveniente de la SEC es que se necesita una buena comprensión de las expresiones regulares para utilizar la herramienta de manera efectiva. Sin embargo, la herramienta puede ser mucho más potente y flexible que Swatch.

¿Dónde puedo obtener más ideas de alerta?

Yo estaba involucrado con la creación del original SANS Top 5 informes de registro . Para la edición de abril de 2009 Cumbre Entrar He actualizado mi presentación para romper ejemplos de informes en categorías de bajo ruido y alto ruido. Algo en la lista bajo nivel de ruido sería un buen candidato para la alerta. Nada en la sección de ruido es mejor seguimiento a través de los informes diarios.

Informes Diarios

Por lo tanto, las listas negras de apalancamiento para generar nuestras alertas en tiempo real. Ahora vamos a aprovechar listas blancas para ayudar a resaltar los patrones de tráfico desconocido pero interesante en nuestros informes diarios.

Cuando se trata de informes diarios, que tienden a gravitar hacia las grandes cifras. ¿Cuáles son las 5 IPs transferencia de datos? ¿Qué dirección de correo electrónico enviado más mensajes? Mientras que las grandes cifras son ciertamente importantes, que ha sido mi experiencia que los eventos de seguridad que usted necesita preocuparse acerca de la mayoría de la generación de menor cantidad de las entradas de registro. Los atacantes inteligentes un gran esfuerzo para permanecer escondido en el ruido. Así que la única forma de encontrarlos es reducir la relación señal a ruido.

I el autor del seguimiento de seguridad perimetral para redes SAN. Uno de los laboratorios que tienen mis alumnos realizar es analizar un archivo de registro de 200.000 líneas. El objetivo es detectar los patrones interesantes, así como formular la revisión en un proceso automatizado. La mayoría de la gente encontrar el escáner de puertos, ya que es bastante ruidoso. Algunos incluso detectar la dirección IP de realizar ataques de la capa de aplicación en el servidor Web. Lo que mucha gente se pierda sin embargo, son las seis líneas que son un indicio bastante claro que un sistema interno ya está en peligro y llamar a casa por órdenes de marcha. ¿Cómo encontrar las 6 líneas? Por listas blancas todo lo que usted entiende y se centra en lo que nunca se deja.

Por lo que es correcto para nuestros informes diarios para darnos bastante gráficos con números grandes. Uno de los informes sin embargo tiene que ser capaz de mover toda la porquería al lado de modo que mejor pueden detectar patrones de la interesante.

Logwatch

Una de las mejores herramientas para hacer una revisión del registro de todos los días es Logwatch . Logwatch se resumen todos los modelos de registro que comprende, además de destacar nada sin una firma predefinida. Mejor manera de entender esta función es ver un ejemplo.

SSHD Muertos: 2 Tiempo (s)

SSHD creados: 1 hora (s)

Conexiones:

Intentos fallidos de las siguientes:

msmith / contraseña de 1.3.247.11: 6 hora (s)

jsmith / contraseña de 1.3.247.11: 5 hora (s)

psmith / contraseña de 1.3.247.11: 4 hora (s)

Usuarios que se conectan a través de sshd:

jjones registrado desde la puesta del sol (1.3.247.9) con publickey: 146 veces (s)

jsmith conectado desde dialup5533.wnskvtao.sover.net (216.114.181.200) using password: 1 Times (s)

jsmith conectado desde dialup984.wnskvtao.sover.net (216.114.163.223) using password: 1 Times (s)

bjones conectado de Charlie (1.3.247.11), utilizando publickey: 444 veces (s)

jsmith conectado desde 192.168.1.173 contraseña utilizando: 2 veces (s)

djones conectado de Charlie (1.3.247.11) using password: 47 veces (s)

** Las entradas sin igual **

Recibió desconectarse de 148.64.147.168: 3: El intercambio de claves no.

Recibió desconectarse de 216.114.160.132: 11: Todos los canales abiertos cerrados

escaneada de 146.87.114.150 con SSH-1.0-SSH_Version_Mapper. No entre en pánico.

escaneada de 211.184.226.99 con SSH-1.0-SSH_Version_Mapper. No entre en pánico.

En el ejemplo anterior Logwatch se está utilizando para resumir la actividad del SSH. Se entiende el servicio que se detiene y se inicia, los intentos fallidos de inicio de sesión, así como los inicios de sesión con éxito. Toda esta información se muestra en formato de resumen por lo que es más fácil de digerir. Por ejemplo, no sabemos exactamente cuándo msmith incorrectamente la contraseña, pero vemos que sucedió en seis ocasiones, todas desde la dirección IP 1.3.247.11. Así que en lugar de tener seis líneas de digerir, sólo tenemos que mirar a uno. Si queremos ver cada entrada de registro específico, siempre se puede hacer referencia a los registros originales.

Ahora mira el "entradas sin igual" sección. Cada uno de estos es un evento que Logwatch no tiene una firma para. En lugar de ignorarlos, lo que ocurriría con un sistema basado en la lista negra, que se resumen a continuación para que podamos revisar. A continuación, tiene la opción de generar una firma para una entrada específica por lo que se clasifican de forma similar al proceso y las secciones de inicio de sesión.

Es evidente que esto nos da lo mejor de ambos mundos. El informe anterior representa un poco más de 650 líneas por valor de las entradas del registro, que se resumen abajo en un fácil leer el informe. Lo más importante, ninguna de las entradas de registro tuvo que ser ignorados con el fin de elaborar este informe resumen.

Más allá de los informes diarios

También puede resultar útil para realizar análisis a largo plazo la tendencia y la minería de datos en los datos de su registro. Esto puede ayudar a revelar los patrones que normalmente no se detectan cuando los registros de una foto pequeña en el tiempo (como 24 horas) se revisa. Posiblemente una de las mejores herramientas disponibles para hacer frente a gran cantidad de datos es Splunk .

Splunk

Splunk está disponible como una versión gratuita que se limita al procesamiento de 500 MB por día, o usted puede invertir en la versión comercial que soporta el procesamiento de datos ilimitado. Splunk es extremadamente flexible en la aceptación de los datos. Puede actuar como un servidor de registro centralizado, o usted puede transferir archivos a través de una serie de métodos como FTP y HTTP. Una vez que se reciben los datos, los índices de Splunk todos los campos en cada archivo de registro. Esto le da la capacidad sin precedentes de ordenación y búsqueda.

Todas las funciones son Splunk son demasiado numerosas para entrar en este post. Compruebe su sitio para obtener una lista completa de las funciones compatibles. ¿Qué Splunk es muy bueno es en la manipulación y elaboración de informes sobre un gran número de entradas de registro. Se pueden indexar, buscar y presentar informes sobre miles de millones de entradas de registro por segundo. Esto hace que sea muy útil para generar informes a largo plazo la tendencia o correr búsquedas guardadas para la minería de datos.

Resumen ejecutivo

Vamos que hemos llegado al final del camino. Esperamos que usted siente que tiene una mejor idea de cómo implementar una solución de registro centralizado, así como la forma de aprovechar para asegurar mejor su entorno. Si usted tiene alguna pregunta, por favor no dude en dejar un comentario. :)

Configurar un sistema de gestión de seguridad de la información-Parte 5

14 de agosto 2009

En mi último post hablé de cómo un servidor de registro utiliza el valor de un mensaje de prioridad para ordenar los mensajes entrantes de registro. En esta entrega voy a hablar sobre las pruebas de conectividad, así como la forma de conseguir distintos artes en el alambre para que presenten sus entradas en el registro a un servidor centralizado.

Requisitos

Para que un sistema para enviar las entradas de registro, tiene que tener soporte para Syslog. Las entradas de registro deben ser transmitidos en texto claro en el puerto UDP/514 en el servidor de registro. Si está utilizando rsyslog en el servidor, TCP/514 es aceptable también.

Enviado entradas de tiempo debe incluir la siguiente información:

  • Un valor de prioridad (en formato <PRI>) al principio de la carga útil
  • El nombre de la aplicación de la presentación de la entrada en el registro
  • El ID de proceso usado por la aplicación
  • El cuerpo de los mensajes de registro

Pero para ser honesto, Syslog no es muy exigente. Se tratará de grabar todo lo enviado a su puerto de escucha como una entrada larga. Si un valor de prioridad no está presente, se registrará la entrada a cualquier archivo que se utiliza para la instalación 1. Normalmente, esto es / var / log / messages.

Prueba de conectividad

Cuando se implementa una nueva configuración, que me gusta para verificar la conectividad entre los primeros clientes de unos pocos y el servidor de registro. Si el registro no funciona, tendrá que ser capaz de aislar el área del problema. Los problemas típicos incluyen:

  • Cliente configurado de forma incorrecta
  • Cortafuegos en el camino (en el cliente, el cable, o el servidor de registro)
  • Servidor configurado de forma incorrecta

Usted tendrá que supervisar el archivo de mensajes en el servidor de registro para asegurar la entrada del registro de prueba se recibe. En el servidor de registro, ejecute el comando siguiente:

tail-f / var / log / messages

La cola se abrirá el archivo de registro de sólo lectura e impresión de los últimos cinco líneas. Como nuevas entradas de registro se reciben, se imprimirá a la pantalla también.

Para generar una entrada de registro de la prueba, me gusta usar Netcat . Netcat puede ser utilizado en cualquier sistema Windows, Linux o UNIX. Desde el sistema de prueba, ejecute el comando:

echo 'esto es una prueba UDP entrada de registro' | nc-u-w 1 <dirección del servidor> registro de 514

Usted debe ver la parte se hizo eco del comando aparece en el directorio / var / log / messages en el servidor de registro. Si no es así, lanzar un sniffer de paquetes y ver si se puede determinar si la falta está ocurriendo. Si desea probar la conectividad de TCP, así, basta con ejecutar el comando de nuevo dejando de lado la Netcat "-u" switch:

echo 'esto es una prueba TCP entrada de registro' | nc-w 1 <dirección de la tala server> 514

Si las dos entradas que se reciban, estamos listos para iniciar los dispositivos que apunta a nuestro servidor de registro.

Hardware de red

La mayoría del hardware de red es compatible a través de Syslog UDP/514. Es sólo una cuestión de ir a través de la documentación y determinar el comando apropiado establecer para el envío de las entradas del registro a un servidor remoto.

Si está utilizando Cisco IOS, ejecute el siguiente modo de configuración global:

<IP registro de la dirección de registro server>

Si desea cambiar la función de registro de "uso local de 7" a otra cosa, el comando es:

servicio de registro <nombre <facility corto

Así que para cambiar el registro de instalaciones de "uso local 3", el comando sería:

el registro de instalación local3

Linux y UNIX

Hay una serie de alternativas Syslog disponible para Linux y UNIX. En esta sección voy a cubrir cómo Syslog y rsyslog que transmita sus mensajes de registro a un servidor remoto.

Syslog

Si el cliente está ejecutando Syslog, tendrá que editar el archivo / etc / syslog.conf. Agregue la línea siguiente al final del archivo:

*.* @ <dirección IP del servidor> registro

Así que un ejemplo sería:

*.* @ 192.168.1.150

Tenga en cuenta el espacio en blanco entre el partido de wild card y la dirección IP remota deben ser caracteres TAB. Si usa espacios, Sysylog no será capaz de analizar el archivo. Guarde y salga del archivo, a continuación, reinicie Syslog para activar los cambios.

rsyslog

Con rsyslog tenemos la opción de reenvío de mensajes de registro a través de nuestra UDP o TCP. En cualquier caso, tendremos que editar el archivo / etc / rsyslog.conf. Para enviar las entradas de largo usando UDP, añadir la siguiente línea al final del archivo:

*.* @ <dirección IP del registro de servidor>: <puerto>

Así que un ejemplo sería:

*.* @ 192.168.1.150:514

Si queremos usar TCP en lugar, simplemente usamos dos "@" símbolos:

*.* @ @ 192.168.1.150:514

Una vez terminado guardar y salir del archivo. Usted tendrá que reiniciar rsyslog para activar los cambios.

Los sistemas Windows

Como se mencionó en un post anterior, Windows no incluye soporte para Syslog. Esto significa que usted necesita software de terceros para convertir los registros en tiempo real y enviarlas a un servidor de registro. El sitio Web Loganalysis tiene una lista de posibles soluciones.

A los efectos de este artículo, me ocuparé de Trampa . Es libre para uso, puede ser con licencia comercial, y tienen un proceso de implementación muy sencilla.

Una vez descargado el software, usted tiene que configurar el sistema. Esto se muestra en la Figura # 1. Trampa necesita saber la ubicación del servidor de registro, así como lo que las instalaciones y el nivel de gravedad de su uso. Una vez completado, haga clic en "Últimos acontecimientos" poción de menú para ver que el Visor de sucesos específicos de las entradas de registro para caja es el reenvío para el servidor de registro.

snare-config

Resumen ejecutivo

En este post hablé de la conectividad de las pruebas a un servidor de registro, así como la forma de configurar los clientes para centralizar sus registros. En el próximo post hablaré de lo que debe buscar en una herramienta de información diaria, así como alertar a tiempo real.

Configurar un sistema de gestión de seguridad de la información-Part4

12 de agosto 2009

En el anterior post hablaba de cómo configurar un servidor de registro que acepte entradas de registro remoto. En esta entrega voy a hablar sobre la forma de ordenar las entradas del registro en archivos específicos.

Instalación, la gravedad y la prioridad

Vamos a hablar de cómo los servidores de registro de averiguar qué archivo para guardar una entrada de registro en cuando se recibió. Los mensajes de registro contienen dos parámetros descriptivos, las instalaciones y la gravedad. Cuando estos dos parámetros se combinan, el valor se conoce como la prioridad del mensaje de registro.

Facilidad

Fondo define el tipo de proceso que genera la entrada de registro. Por ejemplo, todos los servidores de correo, se identifiquen de que sus entradas de registro forman parte de la "mail" instalación. Los procesos de FTP debe utilizar el servicio de FTP, NTP procesos deben utilizar el servicio de NTP, y así sucesivamente. RFC 3164 se definen las instalaciones válida, pero aquí está la lista:

Fondo numérica

Código

0 mensajes del núcleo (Kern)

Un nivel de usuario los mensajes (de usuario) - por defecto si no se especifica

2 sistema de correo (mail)

3 demonios del sistema (demonio)

4 seguridad / autorización (auth)

5 en la syslogd (syslog)

6 líneas subsistema Impresora (LPR)

7 de la red del subsistema de noticias (news)

8 subsistema UUCP (uucp)

9 reloj demonio

10 seguridad / autorización (authpriv)

11 FTP daemon (ftp)

12 NTP subsistema (NTP)

13 del registro de auditoría

14 registro de alerta

15 reloj demonio (cron)

16 0 el uso local (local0)

17 el uso local 1 (local1)

18 el uso local 2 (local2)

19 el uso local 3 (local3)

20 el uso local 4 (local4)

21 el uso local 5 (local5)

22 el uso local 6 (local6)

23 el uso local 7 (local7)

El "uso local", las instalaciones son similares a las direcciones privadas en el mundo IP. Estas instalaciones no están reservados, y están disponibles para que cualquiera lo use como mejor les parezca.

Problemas de las instalaciones

Hay un par de problemas aquí. Para empezar, ¿dónde está la instalación del servidor web? Esta lista fue generada en el año 1987 antes de que los servidores web (o Gopher para el caso) existió. Así que algunos de los servicios que utilizamos hoy en día (VoIP, SQL, etc) no están presentes. Además, algunos de los servicios enumerados normalmente no se utilizan en un entorno corporativo. UUCP y Noticias de la red (NNTP) son excelentes ejemplos.

La falta de servicios actual ha provocado que muchos vendedores que dependen en gran medida de las instalaciones de uso local. Esto puede causar potenciales conflictos cuando nos metemos en nuestra clasificación de entradas de registro. Por ejemplo, Linux utiliza el uso local de 7 a identificar sus entradas en el registro de arranque del tiempo. Apache también utiliza el uso local 7 para los errores de servidor Web. Así que el camino puede ser difícil para nosotros para clasificar los errores de Web y mensajes de arranque en los archivos de registro diferentes.

Otro problema es que no hay una descripción detallada acerca de cada una de estas instalaciones. Esto puede hacer que sea un poco difícil para un programador para identificar cuál de ellos utilizar. Por ejemplo, digamos que he escrito un programa que autentica a un usuario para acceder a la red. Instalación que debemos utilizar? Instalación de 4 y 10 parece el más probable, pero sus descripciones son idénticas. ¿Cómo elegir? Si nuestro programa se ejecuta como un proceso de fondo que en realidad debe elegir tres instalaciones en su lugar?

Usted consigue la idea. La lista no es tan clara como podría ser. No es raro ver a los vendedores de utilizar una instalación diferente de lo que cabría esperar. Por ejemplo, yo he visto vendedores de VPN indecisos en cuanto a las diferencias entre las instalaciones de 4 y 10, por lo que sólo tiene que enviar un porcentaje de las entradas de registro para cada uno.

Gravedad

Severidad define la importancia de la entrada del registro. El mismo RFC 3164 define los niveles de gravedad como:

La gravedad numérica

Código

0 de emergencia: el sistema es inutilizable (emergentes)

Un alerta: hay que tomar medidas de inmediato (de alerta)

2 Crítica: condiciones críticas (crit)

Error 3: Condiciones de error (error)

4 Atención: las condiciones de aviso (advertencia)

5 Nota: condición normal pero significativa (previo aviso)

Informativos 6: mensajes informativos (info)

Depuración 7: depurar los mensajes de nivel (depuración)

Afortunadamente los niveles de gravedad son mucho menos vagas que las descripciones de las instalaciones. Esto significa que son mucho menos confuso para trabajar. Los niveles más altos números de gravedad tienden a ser muy detallado. Esto significa decir que desea enviar los mensajes de depuración a nivel de su servidor de registro podría inundar la red. Use los niveles más altos números de gravedad con precaución.

Prioridad

Cuando una entrada de registro se transmite a un servidor de registro, el primer valor que contiene es la prioridad del mensaje. La prioridad es la instalación y los valores de gravedad combinado por la fórmula matemática siguiente:

(Fondo x 8) + Gravedad = prioridad

Así que digamos que nuestro servidor de correo debe enviar un mensaje de advertencia. ¿Cuál sería la prioridad de ser? El servicio de correo tiene un valor de 2, mientras que las advertencias tienen una gravedad de 4. Por lo que la matemática sería:

(2 x 8) + 4 = 20

Si un servidor de impresión (planta 6) es necesario enviar una entrada en el registro diciendo que está en el fuego (gravedad 0), el valor de prioridad en el mensaje sería:

(6 x 8) + 0 = 48

Cuando una entrada de registro se transmite, el valor de prioridad debe ser encapsulado en menos y más de los signos. Por lo que el valor de prioridad en el mensaje del servidor de correo de arriba sería "<20>", mientras que el servidor de impresión que utiliza "<48>". Una vez más, esto tiene que ser la primera pieza de información que se transmite en el mensaje de registro.

Clasificación de las entradas del registro

El valor de prioridad es utilizado por el registro de servidores para ordenar los mensajes entrantes. Por ejemplo, si quisiéramos todos los mensajes de correo electrónico para ir en el mismo archivo, podríamos decirle a nuestro servidor de registro que todos los mensajes con una prioridad de 16 (2 × 8 +0) y 23 (2 x 8 +7) debe ir a la " maillog "archivo. La mayoría de servidores de registro (como rsyslog) que le permitirá hacer esto numéricamente o mediante el uso de los nombres breve descripción.

ejemplo rsyslog.conf

Aquí hay dos líneas del archivo rsyslog.conf que se incluye en Fedora. Vamos a hablar de lo que realmente están haciendo:

authpriv .* / var / log / secure

*. Info; mail.none; authpriv.none; cron.none / var / log / messages

Estas líneas definen dos de las reglas para la determinación de que las entradas de registro debe ir a los archivos de registro que. La sintaxis de la clasificación es la siguiente:

facility.severity

Así que la primera línea dice que todas las entradas de registro de instalación de 10 (authpriv), independientemente de la gravedad ("*" es un comodin) deben ser enviados en el archivo / var / log / secure.

La segunda línea es un poco más complejo ya que tiene varias condiciones separadas por punto y coma. Estas condiciones de estado:

  • *. Info = Todas las instalaciones, siempre y cuando el nivel de gravedad es información
  • mail.none = No hay entradas servicio de correo de registro, independientemente de la gravedad
  • authpriv.none = No hay entradas instalación authprive registro, independientemente de la gravedad
  • cron.none = No hay entradas cron registro, independientemente de la gravedad

O, para traducir esto a Inglés, de la línea dice "Enviar toda la severidad" info "mensajes a / var / log / messages, excepto aquellos que contengan una instalación de" correo "," authpriv "o" cron ".

Así que con estas reglas, podemos definir cualquier combinación de las instalaciones y los valores de gravedad y que el archivo de registro que nos gustaría dirigirla. La primera vez que lo configuran, seguir con los valores predeterminados. A medida que se empezarán a recoger las entradas del registro se puede modificar las reglas como mejor le parezca.

Doblar el RFC

En un mundo ideal, el RFC sería un ajuste perfecto para las necesidades de todos. Lamentablemente, esto no es siempre el caso. Un buen ejemplo es el registro de las instalaciones. Como se ha mencionado que nos falta para facilitar los servicios de hoy en día, mientras que al mismo tiempo que facilita que nunca va a usar. Una respuesta obvia es reciclar las instalaciones obsoletas con el fin de apoyar los servicios modernos.

Por ejemplo, UUCP (servicio 8) no es ni siquiera el apoyo de los sistemas operativos modernos. Con esto en mente, me gusta usarlo como mi instalación de Windows. Es mi manera de ordenar todas las entradas del registro de Windows en su propio archivo. Para el hardware de red, uso el servicio de noticias de red (servicio 7). Si no está seguro si una instalación está actualmente en uso, modificar el archivo de su servidor de registro de configuración para enviar todas las entradas de registro para esa instalación en un archivo único:

ftp .* / var / log / instalación de la prueba

Si no hay entradas llegar, usted está en buena forma. Hemos de tener en cuenta que un servicio legítimo puede utilizar en una fecha posterior. Por ejemplo, si tres meses a partir de ahora alguien configura un servidor FTP, podemos tener problemas si ya están utilizando las instalaciones de FTP (planta 11). Si no está seguro de que siempre se puede seguir con el uso de las instalaciones locales, ya que es lo que están destinados. Uso local 0 y 7 parecen ser los más utilizados, por lo que evitar cuando sea posible.

Otras opciones de clasificación

Mientras que su no forma parte de la RFC, algunos servidores de registro le dará la posibilidad de ordenar las entradas de registro sobre la base de patrones en el mensaje. Un buen ejemplo es Syslog-NG . Syslog-NG ordenación en función de las instalaciones y la gravedad, pero también puede ordenar sobre la base de IP de origen, la aplicación que generó la entrada de registro, etc Esto le da opciones de clasificación mucho más flexible y puede ser algo a considerar si las instalaciones / gravedad no es granular suficiente para sus necesidades.

Resumen ejecutivo

En esta entrega hablamos acerca de cómo centro de gravedad y se utiliza para ordenar las entradas del registro. En mi próximo post hablaré de cómo conseguir cada uno de nuestros sistemas para enviar mensajes de registro en nuestro servidor centralizado.

Configurar un sistema de gestión de seguridad de la información-Parte 3

11 de agosto 2009

En el último post he cubierto algunas de las preocupaciones arquitectura con el despliegue de un sistema de seguridad de la información centralizada. En este post voy a cubrir el despliegue de un servidor de registros básicos, y verificar que está listo para aceptar las entradas del registro.

Selección de un servidor de registro

Lo primero que tenemos que hacer es seleccionar una plataforma para nuestro servidor de registro. Si nos limitamos a la creación de un laboratorio de pruebas, Windows, UNIX o Linux todos tendrán que tomar decisiones grandes. La elección de Windows podría ser útil para un administrador de Windows, ya que no tendrá que recortar la curva en un nuevo sistema operativo al intentar poner a prueba el registro. Mientras que Windows no es compatible con syslog fuera de la caja, hay algunos excelentes paquetes como servidor Kiwi Syslog y WinSyslog que añadirá soporte para Syslog. Ambos tienen versiones de evaluación y son relativamente baratos de licencia.

Si estamos hablando de la creación de un servidor de producción sin embargo, tendrá que mantenerse alejado de Windows. Windows es famoso por tener una pila IP horrible. Si el hecho anterior "parches" que han paralizado aún más en el interés de frenar la propagación del gusano y el aumento de la velocidad de la interfaz gráfica de usuario. Si bien muchas de estas limitaciones se han eliminado en el 2008 y el servidor de Windows 7, el rendimiento IP es todavía por debajo del par, en comparación con un sistema Linux o UNIX desplegadas en el mismo hardware.

Así que deja de Linux y UNIX, como opciones para un sistema de producción. El que elija dependerá de una elección personal. A algunos les gusta la estabilidad de los demás, mientras que BSD como la flexibilidad de Linux. A los efectos de este documento voy a estar trabajando con un Fedora sistema basado en Linux. Instalación y configuración del sistema operativo es relativamente intuitivo y sencillo.

La aceptación de los registros a distancia

Para aceptar las entradas del registro de los sistemas remotos, las versiones anteriores de Fedora requiere inicializar el demonio syslog (syslogd) con la opción "-r" opción. Esto se hizo mediante la adición de "-r" a la línea de SYSLOGD_OPTIONS del archivo / etc / sysconfig / syslog. Algunas versiones de Linux sigue siendo soporte para Syslog legado, y requieren que añadir "-r" en el archivo de inicialización de Syslog RC. Compruebe la documentación para su distribución específica.

Nuevos sistemas de Fedora sin embargo el apoyo "Syslog confiable" o rsyslog. La aplicación es bastante similar a Syslog simple y llano, a excepción de rsyslog soporta comunicaciones a través de TCP/514, así como UDP/514. En el último mensaje que he descrito que la ejecución de las entradas del registro a través de TCP puede solucionar algunas de las razones por las que suelta las entradas de registro, pero no todos de ellos. Si quieres jugar un poco con el apoyo de TCP, siga adelante y abrir los dos puertos en el servidor de registro.

Para obtener rsyslog para aceptar entradas de registro remoto, tenemos que editar el archivo / etc / rsyslog.conf. Hacia el principio del archivo que usted debería ver lo siguiente:

# Ofrece recepción UDP Syslog

# $ MODLOAD imudp.so

# $ UDPServerRun 514

# Ofrece recepción TCP syslog

# $ MODLOAD imtcp.so

# $ InputTCPServerRun 514

El símbolo "#" (almohadilla), símbolo al principio de la línea le indica al sistema que no procese el resto de la línea. Nosotros usamos esta técnica para hacer comentarios, así como "comentar" los comandos que no desea tener procesados. Comentando las líneas del puerto y MODLOAD especificaciones, podemos prevenir rsyslog de la apertura de un socket de escucha. La ayuda a mantener el sistema en un estado más seguro.

Ya que está configurando un servidor de registro centralizado, que tendrá que abrir los sockets para aceptar entradas de registro remoto. Modificar el archivo / etc / rsyslog.conf archivos para eliminar los símbolos libras apropiado. Ahora, el archivo debe tener este aspecto:

# Ofrece recepción UDP Syslog

$ MODLOAD imudp.so

$ 514 UDPServerRun

# Ofrece recepción TCP syslog

$ MODLOAD imtcp.so

$ InputTCPServerRun 514

Si usted sabe que nunca va a usar TCP, puede dejar las dos últimas líneas comentadas. Una vez terminado guardar los cambios y salga del archivo.

Ahora tenemos que reiniciar el registro para que nuestros cambios sean implementados. Esto se hace en Fedora ejecutando el siguiente comando:

rsyslog reinicio del servicio

Cuando se ejecuta el comando, usted debe dejar de ver rsyslog y empezar con un estado de "OK". Si el cierre no es porque rsyslog no se inicializa en el arranque. Desde la línea de comandos, ejecute el comando "setup" y seleccione "Servicios del sistema" desde el menú principal. Cuando aparezca el menú de servicios, desplácese por la lista hasta encontrar rsyslog. Marque la casilla a la izquierda y luego seleccione "Aceptar". Salga de la utilidad de configuración y rsyslog ahora se inicializa cada vez que se inicie el sistema.

Verificar el puerto de escucha

Lo siguiente que necesitamos para asegurar que nuestro proceso de registro es la aceptación de las entradas de registro remoto. Desde la línea de comandos, escriba "netstat-an | grep: 514". El resultado debe ser similar a lo siguiente:

[Root @ Fubar ~] # netstat-an | grep: 514

tcp 0 0 0.0.0.0:514 0.0.0.0: * LISTEN

tcp 0 0::: 514::: * LISTEN

udp 0 0 0.0.0.0:514 0.0.0.0: *

udp 0 0::: 514::: *

La primera línea nos dice que TCP/514 es escuchar a través de IPv4 en todas las interfaces de red. Dos líneas nos dice que el puerto TCP es también escuchar en cualquier interfaz con una dirección IPv6. Líneas de tres y cuatro son la misma información, a excepción de UDP. Si alguna de las entradas de estado "127.0.0.1:514" en lugar de "0.0.0.0:514", el puerto sólo está obligado a la interfaz loopback. Sólo el sistema local será capaz de llegar a él. Esto puede ocurrir con los sistemas de legado Syslog si se olvidó de ejecutarlos con la opción "-r" switch.

Ahora debe tener un servidor de registro que es capaz de recibir las entradas de registro de entrada. En el próximo post hablaré de cómo estas entradas de registro se clasifican en archivos específicos.

Configurar un sistema de gestión de seguridad de la información-Parte 2

10 de agosto 2009

En mi post anterior, vimos la definición de sus objetivos para una Gestión de la Información de Seguridad (SIM) del sistema. En este post vamos a hablar sobre las preocupaciones de la arquitectura, así como la capacidad de planificación.

Red de comunicaciones

El objetivo será tener uno o más servidores SIM que se recogen las entradas del registro de otros sistemas. Esto, obviamente, tendrá un impacto en la utilización de la red. ¿Cuánto de un impacto dependerá de la cantidad y tipo de sistemas que recogen las entradas del registro de.

UDP/514

Casi todos los sistemas de apoyo a la aplicación Syslog comunicación original que se va todo el camino de regreso al año 1988. La última descripción de esta especificación apareció en RFC 3164 . Si bien esta RFC ha quedado obsoleto por RFC 5424 , RFC 3164 todavía representa la puesta en práctica con el apoyo de la mayoría de los vendedores. Windows es una notable excepción (de propiedad, no hay soporte para Syslog), pero no es un software de 3 ª parte para rectificar esta situación.

Ambos RFC especifica el uso del protocolo UDP en la transmisión de las entradas del registro. El conocido puerto a utilizar es UDP/514. En caso de RFC 3164 y 5424 difieren es en el formato del mensaje de registro. Voy a profundizar en estas diferencias en un artículo posterior.

El amor / odio de la utilización de UDP

En el lado positivo, UDP es sin conexión. Esto significa que se genera menos tráfico que si utiliza TCP. Además, las transmisiones de registro es un proceso unidireccional. El anfitrión de la generación de una entrada de registro envía un paquete al servidor de registro, pero el servidor de registro no responde. Esto significa que puede controlar el flujo de tráfico con el filtrado estático en lugar de la filtración de estado que pondrá menos carga en el dispositivo de control de tráfico. Además, la cabecera UDP es típicamente 1 / 3 - 1 / 4 del tamaño de una cabecera TCP, lo que significa la transmisión de paquetes más pequeños, por tanto, menos gastos generales de la red.

En el lado negativo, UDP es sin conexión. ;) Esto significa que tiene una capacidad mínima de informe de errores. Por ejemplo, si transmitimos una entrada de registro y el cuadro se pierde (por ejemplo una colisión o un firewall de dejar caer el paquete), UDP no tiene la capacidad de detectar que una retransmisión se requiere. Esto significa que es posible para las entradas de registro que van a faltar si desbordamiento de la red. Por otra parte, UDP no tiene la capacidad de control de flujo. Si el servidor de SIM reconoce que es llegar a un nivel que no tiene manera de frenar la transmisión de entrada de las entradas del registro. La única opción del servidor de SIM es lanzar los paquetes de distancia sin procesarlos.

Ni que decir tiene, tenemos que asegurarnos de que estamos bien especificar la capacidad. Si la red o el servidor de SIM se sobrecarga, vamos a perder las entradas de registro. La capacidad de planificación adecuado comienza con la comprensión del impacto de la tala en la red.

Red impacto de la tala

El tamaño máximo de un paquete UDP Syslog tiene diferentes especificaciones en diferentes RFC. El anticuado RFC 3164 define el tamaño máximo de los mensajes como 1024 bytes. RFC 5426 gotas de este tamaño máximo de 480 bytes. Si un vendedor aún después de la especificación de edad, es posible que todavía puede pensar que el tamaño en bytes 1024 es legítimo. Ha sido mi experiencia, sin embargo que la mayoría de los paquetes de entrada de registro varían en tamaño desde 75 hasta 225 bytes, por lo que los máximos son un no-tema.

Los sistemas de Windows, cortafuegos y sistemas de detección de intrusos tienden a generar el mayor mensajes. Hardware de la red tiende a generar el más mínimo mensajes. Si tenemos una red de 100 Mb Ethernet, el máximo teórico sería en algún lugar cerca de 50.000 a 130.000 cuadros por segundo. Esto supone cero el resto del tráfico, que es raramente el caso. A los efectos de la planificación de capacidad, se asume que estará limitada a 5.000 entradas de registro por segundo. Este número podría ser incluso menos si tiene una red ocupada. Tomando algunas medidas de utilización durante el proceso de planificación es la clave.

Syslog a través de TCP

Como se mencionó anteriormente, UDP presenta el problema de que las entradas del registro se pueden perder sin nosotros saberlo. Hay maneras de verificar la capacidad, que voy a cubrir en un post posterior. Algunos se sienten correr Syslog a través de TCP puede corregir este problema. TCP se pueden aprovechar para su fiabilidad a nuestros insurie entradas de registro se reciba correctamente.

Lamentablemente el apoyo TCP para Syslog no estaban cerca estandarizados. Algunos proveedores de soporte TCP, simplemente escucha en TCP/514. RFC 3195 define como Syslog fiable a través del puerto TCP/601, pero su adopción ha sido muy limitado. RFC 5425 define el uso de TLS para asegurar la transmisión de Syslog. Este RFC especifica el uso del puerto TCP/6514. Esta es una especificación nueva y yo estoy al tanto de cualquier persona que lo apoyan todavía.

Así que apoyo a TCP es todo sobre el tablero. Además, el TCP no solucionar el problema por completo. Mientras que el TCP nos dará el control de flujo y fiabilidad en el cable, no puede compensar el hecho de que Syslog en la capa de aplicación no acusar recibo de las entradas de registro. Esto fue por diseño, ya que reduce los gastos generales. El problema es que ni siquiera mediante el uso de TCP todavía podemos perder mensajes dentro de la pila IP y nunca se sabe lo que está ocurriendo.

Así que si quieres probar y transmitir los registros a través de TCP, es solo ir a trabajar entre el cliente de un proveedor específico y el software de servidor. Por ejemplo, usted puede tener que ejecutar Syslog-NG en ambos extremos de la conexión para aprovechar su soporte para TCP. Esto no siempre es práctico, ya que no puede ejecutar el cliente de software en aparatos como los puntos de acceso, switches, routers, etc

Dónde colocar el servidor de registro

La hora de decidir dónde colocar el servidor de registro, tenemos que tener tanto la capacidad de la red y la seguridad en mente. Echa un vistazo a la Figura # 1. Esta es una situación ideal en que se ha aislado el servidor de registro de una red dedicada a operaciones de red. Esto lo aísla de las otras zonas de seguridad y hace que sea mucho más fácil aprovechar el servidor de seguridad para restringir el acceso al servidor de registro.

sim-placement

El dibujo asume que sólo necesita un servidor de registro para todo nuestro entorno. ¿Qué pasa si tenemos 100.000 nodos de perder de vista? Las grandes redes puede necesitar mirar a la agregación de los datos. Por ejemplo, si tengo 10 oficinas en el terreno, que puede necesitar un servidor de registro ubicados en cada uno de ellos recogiendo información de registro local. Cada uno de estos servidores de registro de información de resumen que luego retransmitir a la oficina corporativa de los informes de la red tendencia de ancho. De esta forma mantenemos un alto nivel de visibilidad, mientras que la reducción de la carga de red. Voy a cubrir algunas de las opciones de agregación posible en un artículo posterior.

¿Cuántos sistemas pueden entrar a un servidor de registro único?

No hay una respuesta única a esta pregunta, ya que cada red es diferente. Se va a depender de cómo mucha capacidad disponible en la red y el número de entradas del registro de generar cada uno de estos sistemas. Por ejemplo, yo probablemente podría apuntar 50.000 interruptores en un servidor de registro único, como interruptores, tienden a generar mensajes de muy pocos. Firewalls por otro lado son muy hablador, así que puede ser máximo fuera de la red o el servidor de SIM con sólo 20-50 firewalls. Así que para responder a la pregunta que tenemos que tener en cuenta dos parámetros:

  • ¿Cuánto espacio libre hay en el cable?
  • ¿Cuántas entradas de registro se genera cada host?

La segunda pregunta no es tan sencillo como puede parecer. Por ejemplo, el promedio de escritorio sólo puede generar 40 a 100 entradas de registro por día. Si pulsamos en 1000 las entradas de registro por segundo, la matemática dice que debemos ser capaces de punto 86 millones de ordenadores en un servidor de registro único. El problema es que alrededor del 80% de esos mensajes se generan en el momento del arranque inicial. Si todos los poderes típicamente alrededor de las 9:00 AM, los cambios de matemáticas a un nivel más realista 750 computadoras de escritorio (de nuevo, asumiendo que puede empujar a 1.000 entradas de registro por segundo a través del cable).

Así que no podemos mirar a la cantidad de entradas de tiempo. Tenemos que tomar la hora del día en cuenta también. Esto le permitirá identificar el número real de entradas de registro por segundo que podemos esperar en condiciones peor de los casos. Peor de los casos es el nivel de capacidad que necesitamos para planificar.

Implementar el registro centralizado de las fases

Si usted tiene decenas de miles de sistemas para hacer frente a, es fácil sentirse abrumado con el trabajo relacionado con el despliegue de registro centralizado. El despliegue de la solución en las fases hace que sea más fácil para envolver su cerebro alrededor de todo el proceso.

En primer lugar, comenzar con un servidor de registro único. Puede que no sea capaz de cubrir toda la red, pero tenemos que empezar por alguna parte. Las grandes redes debe considerar un despliegue en la oficina corporativa en primer lugar, saliendo a las oficinas una vez que el sistema corporativo es totalmente controlados y funcional.

Usted también querrá fase en la que los dispositivos que están recogiendo información de. Yo suelo ir con el siguiente orden:

  1. Red de sistemas de detección de intrusos
  2. Cortafuegos
  3. Hardware de red (routers, switches, puntos de acceso, servidores de impresión, etc)
  4. Internet frente a los servidores
  5. Servidores internos
  6. Escritorios internos

Obviamente, usted puede modificar esta lista para satisfacer sus necesidades. Por ejemplo, si usted no planea en la recogida de información desde el escritorio, simplemente deje que salga. Me gusta empezar con los sistemas de intrusión en la red por primera vez como sus entradas de registro son muy adecuadas para investigación de antecedentes, tanto los informes diarios y alertas en tiempo real. Una vez que tenemos un mango de alertas e informes, añadir dispositivos adicionales se vuelve mucho más fácil.

Resumen ejecutivo

En este post he cubierto todas las cosas que hay que tener en cuenta al principio de implementar una solución de registro centralizado. Hemos cubierto a predecir el impacto que tendrá sobre la utilización de la red, la forma de calcular el número de hosts por el registro de servidor, y por qué es importante para implementar la solución por etapas. En el próximo post vamos a empezar a hablar sobre la configuración del servidor de registro centralizado. En concreto, vamos a ver cómo vamos a ordenar las entradas de registro.

Configuración de una Gestión de la Información de Seguridad (SIM) del Sistema - Parte 1

08 de agosto 2009

Tengo un montón de preguntas relacionadas con el registro. Tanto es así que me decidí a hacer una serie sobre cómo implementar la administración de registros. Hay algunos excelentes recursos de registro en Internet, sino que están fragmentadas en su alcance y / o específicos del proveedor (normalmente escrito por los vendedores). Quería crear algo que dependen de un fabricante que tiene su mano a través de todo el proceso de implementación de una solución de gestión de registros.

¿Por qué debería implementar un sistema de gestión de seguridad de la información?

Vamos a ser sinceros, el despliegue de la gestión de registro es difícil y doloroso. Esta es la razón por la cual los administradores para muchos lo evitan como la peste. Es difícil de implementar y un macho salvaje para llevar a cabo la administración a largo plazo. Visitas semanales a la dentista probablemente sería más agradable.

Con todo esto dicho, la administración de registros es probablemente la única solución de seguridad más efectivas que puede implementar. No puede dejarlo de lado y olvidarse de él como un firewall, pero la administración de registros puede darle visibilidad incomparable en el funcionamiento interno de la red. Cuando no su proporcionando información sobre los eventos de seguridad que de lo contrario pueden perder, que está haciendo una doble función para ayudar a solucionar problemas de comunicación y del sistema. Un sistema de registro puede consumir muchos recursos, pero también puede proporcionar una muy alta tasa de retorno.

¿Por qué quieres una tarjeta SIM?

Antes de empezar, la primera pregunta que hay que preguntarse es ¿por qué quiere una solución SIM . ¿Quiere mejorar la seguridad o hay una especificación de cumplimiento es necesario para adherirse a? Podría parecer extraño que quiere distinguir entre los dos, pero los requisitos son drásticamente diferentes. Las normas son mucho más fácil (y barato) para cumplir con que la verdadera seguridad.

Estándares como PCI-DSS requiere que inicie la actividad del usuario, aplicaciones y redes. Sin embargo, tienden a ser muy vaga en la forma en que la información se procesa. Generalmente, usted puede conseguir lejos con caer en un cuadro negro, la generación de algunos informes de gestión de color, y se consideran "compatibles". No puede ayudar a encontrar que el sistema de puerta trasera que está llamando a casa, pero que ha cumplido con las normas.

Las normas tienden a centrarse en el mínimo común denominador. Tienen que ser aplicable a una amplia gama de audiencias, incluyendo a las empresas sin muchos recursos. En lugar de evaluar el riesgo de una organización específica y basándose en los requisitos que hemos puesto el listón baja por lo que se puede lograr por las organizaciones de pequeños y grandes por igual.

Además, para simplificar el proceso, que tienden a centrarse en listas de control. Listas de verificación son frescos porque le dicen exactamente lo que hay que hacer que se queja. Si un auditor puede poner una marca al lado de todos los artículos, se pasa la prueba. El problema es listas tienden a centrarse en los síntomas, no el problema real.

Te voy a dar un gran ejemplo. Tuve un cliente traer a un Asesor de Seguridad Certificado para expedir el certificado para PCI-DSS. Este fue uno de mis clientes que ejecutan una aplicación estricta de control de aplicaciones, por lo que podría mostrar un año y medio la historia de infecciones de malware a cero. Mientras que por cierto, reciben malware durante ese tiempo, se podría probar que hubo cero casos de infección real como todos los ataques de malware se contuvo inmediatamente y eliminado. No muchas empresas pueden reclamar a + años con cero infecciones de malware.

El auditor les ha fallado. PCI-DSS requisito # 5: "El software anti-virus debe ser utilizado en todos los sistemas comúnmente efectuado por malware". Ya que corrió el control de aplicaciones, no anti-virus, se consideró que no cumplen. Si el requisito 5 había sido escrito para identificar un umbral aceptable para la contención de malware, que sin duda han cumplido las especificaciones. Sin embargo, la evaluación de riesgos y las métricas no tienen puntos de la lista de fácil.

Así que si usted desea implementar un SIM para aumentar realmente la seguridad en su entorno, que va a tomar más tiempo y requieren más trabajo que simplemente cumplir con una especificación.

En caso de que construir su propia tarjeta SIM?

Soy un firme creyente de que cualquiera que esté considerando una solución SIM debe comenzar por la construcción de su propio. Si bien hay algunas soluciones comerciales SIM decente por ahí, que se aísla de los trabajos internos del proceso de registro. Esto puede ser una buena cosa, ya que le ahorra tiempo. El problema es que no va a aprender mucho.

Además, la implementación de administración de registros es un viaje. Usted encontrará en el curso de un despliegue que sus necesidades pueden cambiar. Información que inicialmente pensó que era importante, de repente, no lo es. Informes que ni siquiera imaginar, todos los de un salto repentino en la parte superior de la lista. Por la construcción de su propio sistema tendrá más flexibilidad para hacer cambios sobre la marcha. Si más adelante decide que quiere una solución comercial, que están ahora mejor informados de sus necesidades y pueden hacer un mejor trabajo la evaluación de un potencial de compra. Esto es importante, ya que muchas soluciones de registro son caros. Usted no quiere dejar caer un montón de dinero en una solución que no satisfaga sus necesidades a largo plazo.

Te voy a dar un buen ejemplo. La mayoría de los sitios que he trabajado con un principio que los inicios de sesión no son importantes y queremos ver los informes. No les tomó mucho tiempo para saber ver a todos los inicios de sesión no es una completa pérdida de tiempo, como todos los dedos de grasa el teclado de vez en cuando. A continuación, se dan cuenta que quieren algunos umbrales en los datos. Por ejemplo, que sólo quiere ver los inicios de sesión no si tres o más fallos se ven en cinco segundos (lo que indica un ataque automatizado). O sólo muestran los inicios de sesión falló cuando varios nombres de inicio de sesión se utilizan de la misma IP de origen (lo que indica un ataque de contraseña). Así que tratar con algunos sobrecarga de información, se convierten en más cualificada a definir exactamente lo que desea ver.

Resumen

OK, así que hemos cubierto la definición de un enfoque (de seguridad vs. Normas obligatorias), así como la importancia de la inicialmente la construcción de su propio sistema. En la próxima voy a entrar en la arquitectura y la planificación de la capacidad.