Parseando Logs de Suricata con Graylog y Mostrándolos en Grafana 3ra Parte

En este artículo vamos a parsear los registros de log generados por el IDS suricata. Ya tenemos funcionando nuestro servidor graylog y empezaremos a preparar el terreno para capturar dichos registros de logs.

Indices

El procedimiento es similar al que hicimos para zimbra o squid. Creamos ahora el indice de Suricata en System/Indices

Al igual que zimbra y squid, Index shard 4 y Index replicas 0, la rotación del indice del tipo Index time y la retención puede ser de borrado, clausura de un indice de acuerdo al numero máximo de indices o no hacer nada. En mi caso lo puse a rotar mensual y que elimine los indices pasados los 12 meses. En fin existen muchas formas de establecer la rotación. Este indice se crea de manera inmediata.

y con cerebro podemos comprobarlo

Content Pack

Como veremos mas adelante en el IDS Suricata lo haremos registrar sus logs en formato JSON lo cual hizo mucho más sencillo la contrucción de los extractors en el Graylog por lo fácil y amigable que es este formato. El content pack incluye Input de tipo beats, extractores, Tablas lookup, Data adapters para Tablas lockup y Cache para Tablas lookup. Abrimos una entrada en el marketplace de graylog de tipo content pack llamada Suricata Content Pack con un git para estos ficheros de configuración.  Para descargar estos ficheros instalamos git para clonar el repositorio.

#apt-get install git

y seguidamente lo clonamos

#git clone https://github.com/opc40772/suricata-graylog

Ubicaremos los datos CSV de las tablas lookup para convertir mas adelante los número de puertos a nombre de servicios. Del propio git que acabos de clonar seleccionamos el fichero service-names-port-numbers.csv y lo copiamos en /etc/graylog/server.

#cp service-names-port-numbers.csv  /etc/graylog/server

Importamos ahora el fichero de la carpeta Content Pack y para ellos seleccionamos en  System / Content Packs la opción Import content packs para subir el archivo.

Como vemos lo agrega a la lista

Ahora seleccionamos el content pack IDS.

Y lo aplicamos

Streams

Editamos el stream de Suricata en Stream para asociarle el indice que creamos inicialmente. Marcamos que elimine las coincidencias para el stream por defecto All message para que solamente lo almacene en el índice de Suricata.

Creamos una regla para que se almacenen los registros de logs en el indice asociado

Cerebro

Como ya explicabamos anteriormente por  defecto graylog por cada indice que se crea generá su propia plantilla y la aplica cada vez que el indice rota. Si queremos nuestras propias plantillas debemos crearlas en el mismo elasticsearch. Agregaremos el campo real_timestamp que nos será util a la hora de usar grafana y también convertimos a tipo geoip dest_ip_geolocation y src_ip_geolocation a tipo geo_point para poder usarlos en los paneles de World Map ya que graylog no usa este formato.

"real_timestamp": {
   "type": "date",
   "format": "yyyy-MM-dd HH:mm:ss.SSSZ"
},

Y

"dest_ip_geolocation": {
 "type": "string",
 "copy_to": "dst_location"
 },
 "dst_location": {
 "type": "geo_point"
 },
 "src_ip_geolocation": {
 "type": "string",
 "copy_to": "src_ip_location"
 },
 "src_ip_location": {
 "type": "geo_point"
 },

En el git que clonamos ya esta esta plantilla personalizada de la que hablamos y que vamos a importar a elasticsearch a través de cerebro. Vamos a more /index template

Creamos un template nuevo

En el nombre lo rellenamos con suricata-custom y abrimos del git el archivo que tiene el template y pegamos su contenido aquí.

Y seguidamente presionamos el botón create.

Ahora pararemos el servicio graylog para proceder a eliminar el índice mediante cerebro.

#systemctl stop graylog-server.service

En cerebro nos paramos encima del indice y desplegamos las opciones y seleccionamos delete index.

Arrancamos nuevamente el servicio de graylog y este creará el indice con dicha plantilla.

#systemctl start graylog-server.service

Pfsense

Nuestro IDS Suricata esta corriendo como un servicio en el firewall Pfsense y ya esta configurado.

Preparando el terreno en el servidor pfsense.

Determinar el paquete de Filebeat para FreeBSD:
Los paquetes dependen de la versión de freeBSD en ejecución, y esto depende de la versión de pfSense. pfSense 2.3.x se basa en un freeBSD 10. pfSense 2.4.x se basa en freeBSD 11.1
Si está utilizando pfSense 2.3.4 la lista de paquetes nativos actuales está disponible aquí: http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/
Si está utilizando pfSense 2.4 (publicado en octubre de 2017) la lista de paquetes nativos actuales está disponible aquí: http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/

Busque en la lista para determinar el paquete Filebeats disponible. Al momento de escribir, la versión disponible del paquete Filebeats es 6.2.2 y el archivo del paquete se llama beats-6.2.2.txz

Instalando el paquete:
Utilice su programa de terminal de elección para SSH para acceder a PFSense como usuario administrador y elija la opción 8 para ingresar al shell de freeBSD
Instale el paquete usando el siguiente comando:

#pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/beats-6.2.2.txz

El paquete debe instalarse en /usr/local

Ejecutable en: /usr/local/sbin/filebeat

Archivo de configuración en: /usr/local/etc/filebeat.yml

Configurando Suricata para que se registre los logs en formato en JSON.

El formato JSON (JavaScript Object Notation) es un formato de datos que es legible para los humanos y fácil de analizar. Utiliza pares de nombre/valor para describir campos, objetos y matrices de datos, lo que lo hace ideal para transmitir datos, como archivos de registro, donde el formato de los datos y los campos relevantes probablemente serán diferentes entre servicios y sistemas. Al usar registros de formato JSON, significa que no tendremos que gastar mucho esfuerzo configurando Graylog para analizar cadenas y campos que probablemente necesitaríamos hacer si estuviéramos utilizando un CSV u otro formato para los datos de registro.
Es posible configurar el registro en el nivel de cada interfaz dentro de Suricata. Dentro de la pantalla de interfaces de Suricata, haga clic para editar la interfaz relevante(En mi caso WAN) para la que desea recopilar datos de registros de logs y desplácese hacia abajo a la sección ‘Logging Settings’ que se muestra aquí (pfSense Versión 2.4.2):

La configuración relevante es:

  • EVE JSON Log: Marcar
  • EVE Output Type: Seleccione ‘FILE’
  • EVE Log Alerts: Marcar
  • EVE Log Alert Payload
  • EVE Log Alert details: Marque como se muestra en la imagen anterior.

Las otras configuraciones no son relevantes. Una vez que haya configurado las configuraciones anteriores, no olvide hacer clic en el botón ‘Save’ en la parte inferior de la pantalla.

Los registros se pueden encontrar en un subdirectorio relevante para su interfaz dentro de /var/logs/suricata/. El archivo eve.json es el archivo que nos interesa.

Confirme que está recibiendo datos usando cat o tail en el archivo. Si el archivo no se está completando, es posible que deba reiniciar el servicio Suricata desde el panel de control de servicios de pfSense.

Configurar Filebeat para enviar registros

Lo primero que debe hacer es crear un directorio para que Filebeat coloque sus propios registros de loga. El archivo de configuración que crearemos garantizará que Filebeat se registre en esta ubicación para proporcionarnos algunos datos útiles para la depuración:

#mkdir /var/log/filebeat

A continuación, cree un archivo de configuración filebeat.yml que contenga lo siguiente en: /usr/local/etc/filebeat.yml. Asegúrese de utilizar espacios, en lugar de caracteres de tabulación.

#------------------------- File prospectors --------------------------------
filebeat.prospectors:

- input_type: log
  paths:
  - /var/log/suricata/*/eve.json*
  fields_under_root: true
  fields:
    type: "suricataIDPS"
    tags: ["SuricataIDPS","JSON"]

#----------------------------- Logstash output --------------------------------
output.logstash:
  hosts: ["192.168.1.123:5042"]

#---------------------------- filebeat logging -------------------------------

logging.to_files: true
logging.files:
  path: /var/log/filebeat
  name: filebeat.log
  keepfiles: 7

La sintaxis del archivo de configuración real está disponible en el sitio web de Elastic pero este archivo de configuración hace lo siguiente:

  • Procese todos los archivos en subdirectorios en /var/log/suricata/ que coincidan con la especificación de archivo: eve.json*
  • Los archivos serán archivos de log
  • Para cada entrada de log, agregue el campo tipo (type) en el nivel raíz con el valor de ‘suricataIDPS’; esto se usará para determinar el procesamiento dentro de Graylog una vez que el archivo llegue a nuestro servidor de destino.
  • Para cada entrada de registro, agregue las etiquetas ‘SuricataIDPS’ y ‘JSON’. Estas son etiquetas arbitrarias agregadas a los registros para su uso en consultas en en Graylog.
  • Envía los eventos al Graylog en 192.168.1.123:5044
  • Los ficheros de registro de logs en /var/log/filebeat/filebeat.log y no guarde más de 7 archivos de los mismos.

Prueba la configuración:

#/usr/local/sbin/filebeat -c /usr/local/etc/filebeat.yml -configtest
Config OK

Esto debería indicar si hay algún problema con el archivo de configuración. Tenga en cuenta que el archivo de configuración es sensible a las tabulaciones en la sangría, por lo que si ha utilizado estos en lugar de espacios, se puede generar un error y no será evidente cuál es el problema.

Prueba de funcionamiento:

#/usr/local/sbin/filebeat -c /usr/local/etc/filebeat.yml -N

Esto ejecutará filebeat y procesará los registros de Suricata. la opción -N evita que los eventos se envíen al servidor de destino.

Para ver qué está pasando.

#tail -f /var/log/filebeat/filebeat.log

Configure pfSense para iniciar Filebeat al inicio

El instalador del paquete de beats fue lo suficientemente bueno como para crear algunos scripts de inicio de rc.d para Filebeat en:

/usr/local/etc/rc.d

Debido a que esto es pfSense y, por lo tanto, las secuencias de comandos de implementación de FreeBSD personalizadas en este directorio deben tener la extensión de archivo .sh para ejecutarse. Copie el script filebeat:

cp /usr/local/etc/rc.d/filebeat /usr/local/etc/rc.d/filebeat.sh

Si echa un vistazo a la secuencia de comandos, indica que algunas configuraciones se configuren en /etc/rc.conf

De nuevo, debido a la personalización de pfSense, este archivo se sobrescribe en el arranque y no debe editarse. Sin embargo, la creación de un archivo /etc/rc.conf.local se encargará de nosotros. Establezca filebeat para arrancar al inicio y especifique el archivo de configuración de la siguiente manera:

#echo "filebeat_enable=yes" >> /etc/rc.conf.local
#echo "filebeat_conf=/usr/local/etc/filebeat.yml" >> /etc/rc.conf.local

Esto hará que Filebeat arranque al inicio. Reinicie su firewall pfSense y verifique con PS:

#ps aux | grep beat
root 64932 0.0 0.1 10368 2040 - Is 19Mar18 0:00.00 daemon: /usr/local/sbin/filebeat[65093] (daemon)
root 65093 0.0 0.9 54984 18888 - I 19Mar18 5:37.31 /usr/local/sbin/filebeat -path.home /var/db/beats/filebeat -path.conf
root 19915 0.0 0.1 14728 2344 1 S+ 21:17 0:00.00 grep beat

Monitoreo Filebeat

Esto es tan simple como, desde un shell SSH, emitir el siguiente comando. Se mostrará un resultado similar al siguiente.

#tail -f /var/log/filebeat/filebeat.log

Reenviar registros de logs

Una de las ventajas de Filebeat es que realiza un seguimiento de qué archivos y eventos ha procesado y cuáles han sido enviados y confirmados por el destino en este gaso Graylog. Este seguimiento se almacena en un fichero de registro llamado registry. Esto es excelente en producción, pero es probable que deba volver a enviar los mismos registros varias veces durante la configuración de la solución o también en casos de caidas de tensión y se apague abruptamente el pfsense que causa error el filebeat al arrancar por estar el archivo registry corrupto. Para hacer esto, necesita eliminar el registro de Filebeat y reiniciar el proceso. Para lograr esto, realice lo siguiente:

Detenemos el servicio de filebeat

#/usr/local/etc/rc.d/filebeat.sh stop

Eliminar el archivo de registry:

#rm /var/db/beats/filebeat/data/registry

Arrancamos filebeat

#/usr/local/etc/rc.d/filebeat.sh start

Nuevamente se volverán a enviar los registros de log al destino que en este caso es nuestro Graylog.

Ahora en graylog seleccionamos el stream de Susricata  y ya veremos las como va parseando los mensajes de logs creando los campos.

Grafana

Los dashboards de graylog no ofrecen las posibilidades a mi modo de ver que las que tiene grafana por eso nuestro dashboard lo haremos en grafana

Creamos el datasource en grafana el cual nombraremos Suricata-graylog

Comparto con ustedes un dashboard prediseñado en el  sitio de oficial grafana el cual podra importar.

 

Seleccionamos Import dashboard

Subimos el fichero descargado Upload .json file y lo asociamos al datasource creado para el.

Ya podemos ver el dashboard en acción.

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 4

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

7 comentarios

  1. Google Chrome 87.0.4280.66 Google Chrome 87.0.4280.66 GNU/Linux x64 GNU/Linux x64
    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

    Hola….siguiendo los pasos, no puedo crear el template para suricata en Cerebro. Me dice «Error creating template».
    Tengo la versión:
    GRaylog: 3.2.1
    Cerebro: V0.9.2

  2. Google Chrome 86.0.4240.193 Google Chrome 86.0.4240.193 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.193 Safari/537.36

    Tienen algun tutorial de como parsear logs del firewall del pfsense en graylog

  3. Firefox 62.0 Firefox 62.0 GNU/Linux x64 GNU/Linux x64
    Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

    lo que si pude notar es que se tiene que crear para las configuraciones de graylog en el menu

    system/Lookup Tables

    imagino que alli tengo que crear la tabla y el adaptador.

    pero no tengo idea de como hacerlo, no se si estoy en lo correcto aun.

    • Firefox 60.0 Firefox 60.0 GNU/Linux x64 GNU/Linux x64
      Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

      Amigo retiré el comentario anterior. Es que el Content Pack ya incluye Lookup Tables. Fijate si ubicaste bien el archivo service-names-port-numbers.csv y mira ver los permisos del mismo. Saludos.

  4. Firefox 62.0 Firefox 62.0 GNU/Linux x64 GNU/Linux x64
    Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

    hola

    estoy intentando realizar la instalacion del pfsense 2.4.4 con el IDS suricata instalado con e servidor syslog de graylog y grafana. pero tengo el siguiente error. realize varias veces la instalacion, pensando que me habia equivocado, asi que no creo que sea asi, ya lo hice tres veces jejeje en fin, el error es el siguiente

    cuando creo el index en graylog para los logs de suricata en pfsense, no tengo ningun problema, incluso me aparece en cerebro reflejado, es decir todo marcha bien. incluso cuando descargo el paquete de content pack de suricata, y envio el archivo.csv al directorio /etc/graylog/server/ dentro de mi servidor graylog todo marcha perfecto

    cuando intento aplicar el archivo suricata_content_pack me da un error.

    pude revisar los logs del servidor en tail -f /var/log/graylog-server/server.log

    y la linea mas sospechosa es la que dice asi

    ERROR [BundleImporter] Error while creating entities in content pack. Starting rollback.
    java.lang.IllegalStateException: Configured lookup table doesn’t exist

    el log completo parece ser la cadena de eventos que pasa cuando no se cumple la condicion de esta tabla «»

    2019-01-22T23:41:22.158Z ERROR [BundleImporter] Error while creating entities in content pack. Starting rollback.
    java.lang.IllegalStateException: Configured lookup table doesn’t exist
    at org.graylog2.inputs.converters.LookupTableConverter.(LookupTableConverter.java:42) ~[graylog.jar:?]
    at org.graylog2.inputs.converters.ConverterFactory.create(ConverterFactory.java:61) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createConverters(BundleImporter.java:459) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.addExtractor(BundleImporter.java:445) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.addExtractors(BundleImporter.java:422) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createMessageInput(BundleImporter.java:400) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createInputs(BundleImporter.java:356) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.runImport(BundleImporter.java:187) [graylog.jar:?]
    at org.graylog2.bundles.BundleService.applyConfigurationBundle(BundleService.java:112) [graylog.jar:?]
    at org.graylog2.bundles.BundleService.applyConfigurationBundle(BundleService.java:105) [graylog.jar:?]
    at org.graylog2.rest.resources.system.bundles.BundleResource.applyBundle(BundleResource.java:184) [graylog.jar:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_191]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_191]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_191]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_191]
    at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:143) [graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [graylog.jar:?]
    at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [graylog.jar:?]
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [graylog.jar:?]
    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [graylog.jar:?]
    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [graylog.jar:?]
    at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384) [graylog.jar:?]
    at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:224) [graylog.jar:?]
    at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) [graylog.jar:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
    2019-01-22T23:41:22.159Z ERROR [AnyExceptionClassMapper] Unhandled exception in REST resource
    java.lang.RuntimeException: java.lang.IllegalStateException: Configured lookup table doesn’t exist
    at org.graylog2.bundles.BundleImporter.runImport(BundleImporter.java:200) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleService.applyConfigurationBundle(BundleService.java:112) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleService.applyConfigurationBundle(BundleService.java:105) ~[graylog.jar:?]
    at org.graylog2.rest.resources.system.bundles.BundleResource.applyBundle(BundleResource.java:184) ~[graylog.jar:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_191]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_191]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_191]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_191]
    at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:143) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) ~[graylog.jar:?]
    at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) ~[graylog.jar:?]
    at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [graylog.jar:?]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [graylog.jar:?]
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [graylog.jar:?]
    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [graylog.jar:?]
    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [graylog.jar:?]
    at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384) [graylog.jar:?]
    at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:224) [graylog.jar:?]
    at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) [graylog.jar:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
    Caused by: java.lang.IllegalStateException: Configured lookup table doesn’t exist
    at org.graylog2.inputs.converters.LookupTableConverter.(LookupTableConverter.java:42) ~[graylog.jar:?]
    at org.graylog2.inputs.converters.ConverterFactory.create(ConverterFactory.java:61) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createConverters(BundleImporter.java:459) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.addExtractor(BundleImporter.java:445) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.addExtractors(BundleImporter.java:422) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createMessageInput(BundleImporter.java:400) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.createInputs(BundleImporter.java:356) ~[graylog.jar:?]
    at org.graylog2.bundles.BundleImporter.runImport(BundleImporter.java:187) ~[graylog.jar:?]
    … 30 more
    2019-01-22T23:41:23.054Z INFO [InputStateListener] Input [Beats/5a9b0dd0687cf800d1ef207c] is now STARTING
    2019-01-22T23:41:23.058Z ERROR [InputLauncher] The [org.graylog.plugins.beats.BeatsInput] input with ID misfired. Reason: Address already in use.
    org.graylog2.plugin.inputs.MisfireException: org.graylog2.plugin.inputs.MisfireException: org.jboss.netty.channel.ChannelException: Failed to bind to: /0.0.0.0:5042
    at org.graylog2.plugin.inputs.MessageInput.launch(MessageInput.java:158) ~[graylog.jar:?]
    at org.graylog2.shared.inputs.InputLauncher$1.run(InputLauncher.java:84) [graylog.jar:?]
    at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) [graylog.jar:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_191]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
    Caused by: org.graylog2.plugin.inputs.MisfireException: org.jboss.netty.channel.ChannelException: Failed to bind to: /0.0.0.0:5042
    at org.graylog2.plugin.inputs.transports.NettyTransport.launch(NettyTransport.java:155) ~[graylog.jar:?]
    at org.graylog2.plugin.inputs.MessageInput.launch(MessageInput.java:155) ~[graylog.jar:?]
    … 7 more
    Caused by: org.jboss.netty.channel.ChannelException: Failed to bind to: /0.0.0.0:5042
    at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272) ~[graylog.jar:?]
    at org.graylog2.plugin.inputs.transports.NettyTransport.launch(NettyTransport.java:141) ~[graylog.jar:?]
    at org.graylog2.plugin.inputs.MessageInput.launch(MessageInput.java:155) ~[graylog.jar:?]
    … 7 more
    Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind0(Native Method) ~[?:1.8.0_191]
    at sun.nio.ch.Net.bind(Net.java:433) ~[?:1.8.0_191]
    at sun.nio.ch.Net.bind(Net.java:425) ~[?:1.8.0_191]
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) ~[?:1.8.0_191]
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) ~[?:1.8.0_191]
    at org.jboss.netty.channel.socket.nio.NioServerBoss$RegisterTask.run(NioServerBoss.java:193) ~[graylog.jar:?]
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391) ~[graylog.jar:?]
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315) ~[graylog.jar:?]
    at org.jboss.netty.channel.socket.nio.NioServerBoss.run(NioServerBoss.java:42) ~[graylog.jar:?]
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) ~[graylog.jar:?]
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) ~[graylog.jar:?]
    … 3 more
    2019-01-22T23:41:23.059Z INFO [InputStateListener] Input [Beats/5a9b0dd0687cf800d1ef207c] is now FAILED

    he buscando por internet una solucion para este problema, pero no encuentro nada relacionado, asi que no hay mucho del tema

    aparentemente, no esta esta tabla por defecto cuando realizo la instalacion del paquete. en la base de datos mongo.

  5. Google Chrome 71.0.3578.98 Google Chrome 71.0.3578.98 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

    There is an error with the suricata content pack. I was able to deploy the first dashboard. But the second one with suricata dashboard is not working. Importing and applying the suricata content pack gives an error

    • Firefox 60.0 Firefox 60.0 GNU/Linux x64 GNU/Linux x64
      Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

      Could you show the error or the errors that importing the content pack gives you?

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*