BLOG IT

  Cuando tenemos que diseñar una arquitectura de Splunk , una de las cosas claves a tener en cuenta son los puertos y protocolos de comunicación. Aquí os dejo un diagrama muy útil donde se explica. NOTA: Existen algunas otras versiones más extensas, con algún detalle más, googleando con este mismo titulo se encuentran sin problemas.

SHC e Indexers Siguiendo con el anterior post , en este vamos a hablar de la arquitectura en alta disponibilidad o cluster de Splunk . A la hora de “clusterizar” nuestro entorno de Splunk, podemos dar alta disponibilidad a las siguientes capas: Search Head Cluster (SHC): Aquí damos alta disponibilidad a la capa de acceso de usuarios, bquesquedas, cuadros de mando… Clusters de indexación: Con esta configuración damos alta disponibilidad a la parte de almacenado e indexación de los eventos. Multi Site Cluster: Esta cofiguracion nos permite tener nuestro cluster (del tipo que sea) distribuido varias localizaciones. Cualquier tipo de ellas combinadas   Cluster MultiSite  Algunos nuevos elementos que vamos a necesitar para ello son: Search Head Deployer : esta instancia es la encargada de desplegar las App a los miembros de nuestro SHC y otras configuraciones Index Cluster Master : Desde esta instancia desplegaremos las App a nuestos indexers, además gestiona la replic...

Voy a crear una serie artículos explicando los diferentes tipos de arquitecturas de Splunk y sus componentes. De forma rápida, los principales componentes de Splunk: Search Head (SH):  Es el encargado de realizar las búsquedas sobre los datos, ejecutar alarmas, contiene cuadros de mandos, login de usuarios. Suele demandar muchas CPUs Indexador (IDX):  Es donde se almacena toda la información, y donde nuestros SH irán a buscarla. Aquí debemos disponer de almacenamiento. Lo normal es disponer de un almacenamiento lo mas rápido posible para datos recientes, y otro "normal" para los datos históricos. Forwarder:  El encargado de recoger y envinar la información a nuestro IDX, en estos dos artículos ya hable de ellos  Splunk Forwarder   y   Forwarder VS Heavy Forwarder Ya veremos más adelante que pueden existir otros componentes. Todos estos componentes, se pueden agrupar o distribuir de la siguiente forma: ...

Después de la anterior entrada,  Visualizaciones Splunk Capitulo 1 , continuo en esta explicando algunos trucos que uso a la hora de realizar cuadros de mando o informes en  Splunk . Algo sencillo pero que en ocasiones suele funcionar muy bien es activar el " dark theme "  Por supuesto podemos usar  visualizaciones externas , creadas por terceros, pero con cuidado de problemas de compatibilidad, actualizaciones... Existen dos fuentes muy buenas, que yo consulto casi a diario, son,  Splunk Base   y el  Blog de Splunk , , Splunk Apps En lo que se refiere a tomar ideas, o incluso saber cómo hacer ciertos indicadores, drilldowns... una app básica que uso desde hace años  Splunk Dashboard Example s Otra App que no es tan veterana, de hecho se encuentra en Beta, pero que esta genial para  hacer Dashboards de forma "más sencilla" es  Splunk Dashboards App (Beta) ,  yo la he u...

Una de las grandes bondades de Splunk es la posibilidad de crear cuadros de mando o informes . En algunas ocasiones, como puede ser un POC , con hacer unos simples gráficos de tarta, barras y unas tablas, puede servirnos, para demostrar la potencia de Splunk. Pero en otras ocasiones nos podemos enfrentar grandes a proyectos de visualización de datos, donde se tiene que hilar muy fino en el tipo de gráfico, colores, orden de los gráficos... Nos podemos encontrar con dos perfiles de empresas: Empresas que llevan tiempo trabajando en proyectos similares, y tienen gente con las ideas muy claras, por lo que suele ser mas facil abordar algunas tareas. Empresas que están empezando y además no tienen mucha gente especializada en el campo de la presentación de datos, o no tienen tiempo para dedicarle al proyecto. Si estamos en este segundo caso, desde mi experiencia, yo siempre parto de las siguientes premisas: Personalizar al máximo la apariencia de S...

                                                                    Hace ya tiempo hice un   post , sobre los  Data Model , pero me deje una cosa en el tintero, y creo que viene perfecto para poder hacer un post, y explicar uno de los grandes beneficios de los Data Model , la  normalización . Creo que es uno de los puntos clave cuando nos encontramos un entorno con varias fuentes, por ejemplo dos fabricantes distintos de  firewall  (F1 y F2 en este caso) y nuestro  LDAP , nos podemos encontrar diferentes campos con el mismo significado pero diferente nombre, por ejemplo, puede que el campo usuario se llame  user_name  en el F1  user_n  en el F2 y en el LDAP sea  account_name . Todo esto Splunk lo tiene más que pensado, y para ello ...

Unos de los momentos críticos y que deben ser planificados son las actualizaciones de versión. Hace unos días Splunk liberó la versión 7.3, la cual trae bastantes novedades, aunque en este post no voy a explicar estas novedades, sino algunas cosas que debemos tener en cuenta antes de actualizar. La idea de este post me vino a la cabeza después de leer este articulo del blog de Splunk, desde luego esta bien pasarse de forma regular a ojear los post. En este post explican algunas de las mejores practicas, como leerse primero siempre los siguientes enlaces: Leer las novedades y cambios en la versión, aqui   Crear un plan detallado de la migración, identificando los componentes, aquí un ejemplo muy bueno, aqui me gustaria destacar dos puntos Backup, backup, backup, esto nunca sobra, Splunk tiene sus particularidades, ya lo explicaré en un futuro post Entorno de pre-producción, no siempre es posible, pero cuanto mas compleja sea nuestra arquitectura más necesario es R...

Siempre que realizamos una implementación de Splunk , u otro producto, una de las cosas que debemos cuidar es el tuning y aplicar las mejores practicas recomendadas por el fabricante. A continuación os pongo unas configuraciones básicas que siempre realizo al desplegar/montar un sistema Splunk Ulimits https://answers.splunk.com/answers/13313/how-to-tune-ulimit-on-my-server.html https://docs.splunk.com/Documentation/Splunk/7.2.6/Troubleshooting/ulimitErrors HTTP thread https://docs.splunk.com/Documentation/Splunk/7.2.6/Troubleshooting/HTTPthreadlimitissues Transparent huge memory https://docs.splunk.com/Documentation/Splunk/7.2.6/ReleaseNotes/SplunkandTHP Aquí se explican algunas consideraciones básicas

Uno de los puntos mas importante en despliegues de Splunk , y algo que debería ser una costumbre en todos los primeros pasos de despliegues, es la instalación y configuración de certificados. En toda instalación de Splunk, podríamos distinguir tres puntos donde instalar certificados: Web: He llamado así al certificado que publicaremos para acceso de nuestros usuarios, es decir, para que la información entre el navegadores de los usuarios y nuestro SH este cifrada. Este certificado lo configuramos en nuestro web.conf y server.conf . Aquí os dejo unos enlaces donde explica como hacerlo: https://docs.splunk.com/Documentation/Splunk/7.2.6/Security/AboutsecuringauthenticationtoSplunkWeb https://answers.splunk.com/answers/506572/installing-a-ssl-certificate-in-splunk.html Envío de datos al IDX : Por defecto, al información que mandamos a nuestro indexador no va cifrada, para ello tenemos que habilitar en nuestros forwarder y Searh Head que este envío se haga de forma cifrada,...

Uno de los mayores problemas que nos podemos encontrar para hacer pruebas de tiempo real o demos, es la falta de alguna fuente que nos provea de estos eventos. Splunk ya pensó en esto hace tiempo, y tiene una App , la cual nos genera estos eventos en tiempo real, con la que podemos hacer infinidad de pruebas, o incluso podemos llevar a una demo. En este enlace se nos explica con detalle todo el detalle de instalación, configuración...

Los " Data Model " de Splunk   nos pueden servir de gran ayuda en muchos proyectos, en el caso de tener un gran cantidad de registros (miles de millones). Aunque esta es una novedad introducida hace tiempo, aún existen despliegues donde no se usan, es bastante habitual verlo en las App de seguridad, como por ejemplo Palo Alto Algunas de las ventajas de disponer de nuestro Data Model Nos permite crear modelos de datos acelerados, podemos elegir por ejemplo disponer de los últimos 30 días acelerados. Además, poder crear campos ad hoc, crear extracciones, enriquecer la información con lookups..., y todo esto mantenerlo en un modelo aparte a los datos raw. Con esta información enriquecida, podemos usar los Pivot , estos nos permite dar acceso a usuarios a construirse sus propios informes, de una manera muy sencilla y visual, sin tener que conocer SPL, aquí os dejo un par de links Doc oficial   Video De esta manera podemos conseguir acceder a nuestra información d...

El otro día encontré un articulo en el blog de Splunk titulado " Splunk Validated Architectures " el cual me pareció muy interesante, ya que explicaba los pasos a seguir a la hora de desplegar una arquitectura de Splunk , y las consideraciones que deberíamos de tomar a la hora de diseñar nuestra arquitectura... Una cosa ademas que me gusto mucho, fue el uso de códigos para definir el tipo de arquitectura por capa (SHC, single node...) os lo adjunto la URL .

Uno de los mayores problemas de Splunk es el control de versiones de una App o un dashboard , hablando siempre de la parte de presentación, ya que la parte de indexación apenas suele tener cambios. Esto se complica cuando ademas tenemos sobre una misma App a varias personas creando dashboards o reports. Splunk por desgracia no dispone de un sistema nativo de control de versiones. Hace unos meses, pusieron en Splunk base la siguiente App , la cual nos permite llevar un control de versiones, yo no la he podido probar aún, pero si alguno la probáis, podéis poner vuestros comentarios. Hace tiempo, cuando me encontré con este problema, después de buscar, encontré la  esta solución , esta muy bien si tenemos un Deployment Server, en caso de no disponer de uno, podemos intentar adaptarlo a nuestro entorno, desplegando directamente sobre el SH, o nuestro entorno StandAlone

Cuando empezamos a trabajar con una tecnología nueva, nos encontramos con problemas que no sabemos muy bien como solucionar, donde encontrarlo los logs, como hacer debug... Muchas veces nos lanzamos a leer la doc oficial del fabricante, blog, google... un día navegando encontré este enlace  el cual me parece muy útil. De todas formas sigo pensando que lo mejor es buena formación

Una duda típica a la hora de recoger/enviar eventos a los indexadores, es que tipo de forwarder usar. Como norma general lo ideal es usar siempre Universal Forwarder (UF) ,  este es un agente muy ligero, que apenas consume recursos del host donde se instala, incluso existe una versión para Raspberry Pi, aquí . Existe otro tipo, llamado  Heavy Forwarder (HF),  este es mas pesado, pero dispone de funcionalidades adicionales, como: Posibilidad de filtrar/descartar eventos Posibilidad de conectarte a varias DB a través de la App DB Connect Realizar enrutado de información compleja. Esto son grandes ventajas, pero a cambio, el envío de información es mas pesado, y puede sobrecargar la red, ya que el HF parsea los eventos, y esto hace que incrementen su tamaño. Por esto, siempre es recomendable usar UF, salvo que no que nos encontremos en alguno de los tres casos anteriores. Aquí is dejo un enlace del blog de Splunk donde lo explican en detalle,  Universa...

Un componente casi imprescindible, pero no obligatorio en casi cualquier despliegue de Splunk es el F orwarder (FW). Este componente es el encargado de recolectar, enrutar, filtrar información... sobre nuestros datos, se puede instalar en maquinas Windows y Unix, puede recoger información de una BBDD o de una web, vía REST API, por ejemplo, y enviarlo directamente a nuestro indexador o incluso a otro FW. Por supuesto puede enviar la información cifrada, comprobar si ha llegado al destino, dispone de una cache que puede retener los datos (muy útil cuando trabajamos con eventos enviados por un router, firewall o dispositivo IOT) y muchas otras funcionalidades que lo hacen tan interesante, pero lo que no pueden hacer, es indexar información En nuestra arquitectura podemos tener cientos de FW desplegados, en este caso lo ideal es montar un Deploytment Server , el cual se encarga de enviar configuraciones a nuestros FW, y así nos evitamos tener que ir uno a uno. Si hablamos de FW, d...

Voy a comenzar este "reenganche" hablando de un software con el que llevo trabajando años, se llama Splunk , este es un software, o plataforma, como me gusta denominarlo a mi, el cual es capaz de ingerir gran cantidad de eventos/log (BBDD, syslog, REST API...) y poder representar esta información mediante gráficos, lanzar alarmas (email, sms script...) y todo esto en tiempo real y desde una interfaz web. Dispone muchísimas Apps desarrolladas y mantenidas por la comunidad, fabricantes (CISCO, Palo Alto, Splunk...) las cuales nos permiten integración directa con sus productos, en algún post os pondré ejemplos de algunas de ellas, mientras os pongo un enlace . Ademas por el tipo de software que es, cada proyecto, es un reto, ya que cada proyecto puede ser un caso de uso totalmente nuevo, por ejemplo pueden hacerse proyectos la visualización de gráficos de log de servidor de aplicaciones (IIS, apache...) puede hacer de "coctelera" que ingiera eventos de multiples...