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.
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
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
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.
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.
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.
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
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?