> For the complete documentation index, see [llms.txt](https://hacking-3.gitbook.io/barre/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-3.gitbook.io/barre/apuntes/blue-team/splunk/plataforma.md). # Plataforma ### 1. Arquitectura General y Componentes #### 1.1 Roles de la Plataforma | Componente | Rol | Observaciones | | ------------------------ | ---------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Universal Forwarder (UF) | Recolecta datos de endpoints; no parsea ni indexa | Mínimo footprint (\~100 MB RAM); gestionado mediante Deployment Server | | Heavy Forwarder (HF) | Parsea, enruta, filtra y enmascara antes de reenviar | Instalado en el origen (sitio cliente / DMZ); requiere KV Store saludable para DB Connect | | Indexer | Almacena, indexa y sirve búsquedas | CPU-intensivo durante indexación; I/O-intensivo durante búsqueda | | Search Head (SH) | UI, dashboards, alertas, dispatch de búsquedas | Aloja KV Store (MongoDB embebido); en producción, cluster de 3+ nodos | | Deployment Server (DS) | Gestión centralizada de configuración de UF/HF | Push de apps vía `serverclass.conf`; los clientes hacen polling cada 60s (configurable) | | Cluster Manager | Coordina el indexer cluster (RF/SF, failover) | No indexa ni busca; supervisa peers y gestiona fixups | | SHC Deployer | Distribuye apps/config al Search Head Cluster | Instancia independiente; distinto del Deployment Server | | License Manager | Control de volumen de ingesta diario | Desactiva búsqueda tras 5 violaciones consecutivas en 30 días | #### 1.2 Aislamiento Multi-Entorno En despliegues compartidos (multi-tenant), el aislamiento de datos se garantiza exclusivamente a nivel de **índice**: ``` index = _ # ej: acme_fw, acme_win, acme_edr, contoso_fw, contoso_vpn ``` Los permisos de rol (`authorize.conf`) restringen qué índices puede consultar cada usuario/rol. Un analista de un entorno no puede ver los índices de otro aunque comparta infraestructura. #### 1.3 Buckets y Ciclo de Vida del Dato ``` Hot (escritura activa) → Warm (sellado, buscable) → Cold (comprimido, buscable) → Frozen (archivado o eliminado) ``` El movimiento entre fases se rige por `indexes.conf` (`maxHotBuckets`, `maxWarmDBCount`, `frozenTimePeriodInSecs`, `coldToFrozenDir`). Ver sizing en `Gestión_SIEM.md` §2.5. ``` # indexes.conf - ciclo de vida por índice [fw_production] homePath= $SPLUNK_DB/fw_production/db coldPath= $SPLUNK_DB/fw_production/colddb thawedPath= $SPLUNK_DB/fw_production/thaweddb frozenTimePeriodInSecs= 7776000 # 90 días maxHotBuckets=3 maxWarmDBCount=300 maxDataSize= auto_high_volume ``` #### 1.4 Pipeline de Indexación ``` Input → Parsing → Merging → Typing → Index - Input: leer datos de la fuente - Parsing: event breaking, timestamp extraction, charset detection - Merging: LINE_MERGE para eventos multilínea - Typing: aplicación de props.conf y transforms.conf a nivel index-time - Index: escritura en disco, generación de tsidx ``` *** ### 2. Indexer Clustering - Arquitectura El indexer clustering replica los buckets entre varios peer nodes para garantizar disponibilidad ante la caída de un indexer. #### 2.1 Componentes | Rol | Función | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Cluster Manager** (antes “master node”) | Coordina el cluster: asigna buckets primarios, gestiona rebalanceo, decide fixups tras la caída de un peer. No indexa ni busca. | | **Peer Node** | Indexer que forma parte del cluster; almacena réplicas de buckets propios y de otros peers | | **Search Head** | Consulta el Cluster Manager para conocer qué peer tiene la copia searchable de cada bucket | #### 2.2 Replication Factor (RF) y Search Factor (SF) | Parámetro | Definición | Valor recomendado | | --------------------------- | ---------------------------------------------------- | --------------------------------------------- | | **Replication Factor (RF)** | Número total de copias de cada bucket | 2 (mínimo), 3 para entornos críticos | | **Search Factor (SF)** | Copias en formato searchable (con `.tsidx` generado) | SF ≤ RF; SF=2 con RF=3 es el balance habitual | > **Regla:** SF debe ser ≤ RF. Con RF=2, SF=2, cualquier fallo de un único peer mantiene plena capacidad de búsqueda. ``` # server.conf en el Cluster Manager [clustering] mode= manager replication_factor=3 search_factor=2 pass4SymmKey= cluster_label= ``` ``` # server.conf en cada Peer Node [clustering] mode= peer manager_uri= https://:8089 pass4SymmKey= ``` ``` # server.conf en el Search Head [clustering] mode= searchhead manager_uri= https://:8089 pass4SymmKey= ``` #### 2.3 Multisite Clustering Para despliegues con indexers en más de un datacenter: ``` [clustering] mode= manager multisite=true available_sites= site1,site2 site_replication_factor= origin:2,site2:1,total:3 site_search_factor= origin:1,site2:1,total:2 ``` `site_replication_factor`/`site_search_factor` controlan cuántas copias por sitio - clave para tolerar la pérdida completa de un site. #### 2.4 Failover y Fixups Cuando un peer cae, el Cluster Manager detecta la ausencia de heartbeat y dispara un **fixup**: promueve réplicas existentes a primarias y, si RF/SF quedó por debajo del objetivo, ordena nuevas réplicas entre los peers restantes. La búsqueda sigue disponible sobre las copias searchable existentes durante el fixup. #### 2.5 Comandos Operativos ```bash # Estado general del cluster (ejecutar en el Cluster Manager) /splunk/bin/splunk show cluster-status --verbose # Ver buckets no replicados/no searchable (deuda de RF/SF) /splunk/bin/splunk list cluster-generation # Forzar rolling restart controlado del cluster (tras cambios de config) /splunk/bin/splunk rolling-restart cluster-peers # Poner un peer en modo mantenimiento antes de una intervención /splunk/bin/splunk edit cluster-config -manager_uri https://:8089 -mode maintenance # Ver peers activos y su estado /splunk/bin/splunk show cluster-peers --verbose # Reparar buckets dañados /splunk/bin/splunk fix cluster-fixup ``` #### 2.6 SPL de Monitorización del Indexer Cluster ``` # Errores del Cluster Manager index=_internal source=*splunkd.log component=CMMaster | stats count by log_level, message | sort -count # Buckets pendientes de replicación | rest /services/cluster/master/fixup | table title, target, type # Peers con buckets desincronizados | rest /services/cluster/master/peers | table label, status, bucket_count, search_state, replication_factor_met, search_factor_met ``` *** ### 3. Search Head Clustering #### 3.1 Componentes | Rol | Función | | ------------------ | --------------------------------------------------------------------------------------------------------- | | **Captain** | Nodo elegido dinámicamente; coordina dispatch de búsquedas programadas y replicación de knowledge objects | | **Cluster Member** | Cada search head del cluster; puede convertirse en captain | | **Deployer** | Instancia (no miembro) que distribuye apps/configuración a todos los miembros | #### 3.2 Elección Dinámica de Captain La elección usa un algoritmo tipo Raft: si el captain deja de responder, los miembros restantes eligen uno nuevo automáticamente. ```bash # Ver quién es el captain actual /splunk/bin/splunk show shcluster-status # Bootstrap inicial del cluster (una sola vez, en el primer miembro) /splunk/bin/splunk bootstrap shcluster-config \ -servers_list ",," \ -auth admin:changeme # Forzar reelección de captain /splunk/bin/splunk transfer shcluster-captain \ -mgmt_uri https://:8089 ``` #### 3.3 Deployer - Distribución de Apps ```bash # En el Deployer: colocar la app en shcluster/apps y publicarla cp -r mi_app /splunk/etc/shcluster/apps/ /splunk/bin/splunk apply shcluster-bundle \ -target https://:8089 \ --answer-yes # Verificar estado de distribución del bundle /splunk/bin/splunk show shcluster-bundle-status ``` > El Deployer distribuye apps y configuración estática. Los **knowledge objects creados en Splunk Web** (dashboards, alertas, macros) se replican automáticamente entre miembros del cluster vía el mecanismo de replicación del SHC - no requieren el Deployer. #### 3.4 Resincronización tras Fallos de Replicación ```bash # Si un miembro queda con configuración desincronizada /splunk/bin/splunk resync shcluster-replicated-config # Ver artefactos de búsqueda replicados pendientes /splunk/bin/splunk show shcluster-status --verbose | grep -i replication # Reiniciar un miembro sin eliminar del cluster /splunk/bin/splunk restart ``` #### 3.5 SPL de Monitorización del SH Cluster ``` # Estado de replicación del SHC index=_internal source=*splunkd.log component=SHPeer OR component=SHCReplicator | stats count by log_level, component, message | sort -count # Búsquedas despachadas por captain index=_internal source=*scheduler.log status=completed earliest=-1h | stats count, avg(run_time) as avg_run by app, savedsearch_name | sort -count | head 20 ``` #### 3.6 Consideraciones en Entornos Compartidos En un SH cluster compartido (multi-tenant), el captain gestiona el dispatch de las búsquedas programadas de todos los entornos - un pico de carga de un cliente puede afectar el SLA de búsqueda de otros. Usar Workload Management (§11) para aislar cargas y garantizar SLAs por entorno. *** ### 4. SmartStore #### 4.1 Qué Es y Cuándo Usarlo SmartStore desacopla el almacenamiento de buckets warm/cold hacia **almacenamiento de objetos remoto** (S3, S3-compatible, Azure Blob, GCS), manteniendo en el indexer solo una **caché local** de los buckets consultados recientemente. | Escenario | ¿SmartStore recomendado? | | ----------------------------------------------------------------------------------- | ---------------------------------------------------- | | Retención larga (>1 año) con presupuesto de almacenamiento local limitado | Sí | | Volumen >1 TB/día con necesidad de escalar almacenamiento independiente del cómputo | Sí | | Entorno pequeño (<50 GB/día), retención corta | No - la complejidad no compensa | | Cliente exige que el dato nunca salga de sus instalaciones | Evaluar - requiere object storage propio del cliente | #### 4.2 Arquitectura ``` [Indexer] --escritura síncrona hot bucket (local)--> [Disco local] [Indexer] --al rodar a warm--> [Cache Manager] --sube asíncronamente--> [Remote Object Storage: S3/Azure/GCS] [Búsqueda] --cache miss--> [Cache Manager descarga bajo demanda] --> [Disco local (caché)] ``` El **Cache Manager** de cada peer decide qué buckets mantener en caché según política LRU y espacio disponible. #### 4.3 Configuración Básica ``` # indexes.conf - configuración a nivel global o por índice [default] remotePath= volume:remote_store/$_index_name maxDataSize= auto [volume:remote_store] storageType= remote path= s3:///idx remote.s3.access_key= remote.s3.secret_key= remote.s3.endpoint= https://s3..amazonaws.com remote.s3.encryption= sse-s3 ``` **Otras opciones de object storage:** | Proveedor | path ejemplo | Parámetros clave | | --------------------- | -------------------- | --------------------------------------------------- | | AWS S3 | `s3:///idx` | `remote.s3.endpoint`, `remote.s3.encryption` | | Azure Blob | `blob://` | `remote.azure.access_token`, `remote.azure.account` | | GCS | `gs://` | `remote.gs.endpoint`, credenciales service account | | S3-compatible (MinIO) | `s3://` | `remote.s3.endpoint = https://:` | #### 4.4 Consideraciones Operativas * Requiere ancho de banda estable entre indexers y el object storage - la latencia de red impacta el tiempo de búsqueda sobre buckets no cacheados. * El cache eviction agresivo bajo presión de disco puede degradar búsquedas históricas frecuentes - dimensionar la caché local (`maxCacheSize`) según el patrón real de consultas. * No aplica a hot buckets (siempre en disco local hasta rodar a warm). * Usar cifrado del lado del servidor en S3 (`sse-s3` o `sse-kms`) si el cliente tiene requisito de cifrado en reposo. *** ### 5. Distributed Search #### 5.1 Modelo El Search Head no almacena datos: despacha cada búsqueda a los indexers (search peers), agrega los resultados y los devuelve al usuario. ``` # distsearch.conf en el Search Head [distributedSearch] servers= ,, ``` #### 5.2 Knowledge Bundle Antes de despachar una búsqueda, el Search Head replica su knowledge bundle (apps, lookups, macros, props/transforms) a cada peer. ```bash # Ver estado de la replicación del bundle /splunk/bin/splunk list search-server # Forzar replicación manual del bundle /splunk/bin/splunk _internal call /services/admin/distributedsearch/kick ``` #### 5.3 Federated Search Permite a un Search Head consultar índices de **otra instancia Splunk separada** (otra plataforma o Splunk Cloud) sin reenviar datos físicamente. Configurado via `Settings → Federated Search`. **Uso típico:** escenarios de M\&A donde una organización mantiene su propia instancia temporalmente y se requiere correlación cruzada sin migrar datos de inmediato, o entornos híbridos cloud + on-premise. #### 5.4 Rendimiento en Búsqueda Distribuida ``` # Tiempo de respuesta por peer (detectar indexer lento/degradado) index=_internal source=*metrics.log group=dispatch component=dispatch | stats avg(remote_search_time) as avg_time by peer | sort -avg_time # Carga de búsquedas por usuario (detectar abusos) index=_audit action=search info=completed earliest=-1d | stats count as searches, avg(total_run_time) as avg_sec by user | sort -searches ``` *** ### 6. Gestión de Licencias #### 6.1 Modelo de Licenciamiento | Concepto | Descripción | | ------------------- | ------------------------------------------------------------------------------- | | **License Manager** | Instancia central que valida el volumen de ingesta diario de todos los indexers | | **License Pool** | Agrupación de indexers que comparten una cuota de volumen | | **License Stack** | Conjunto de licencias del mismo tipo combinadas | | **Peer License** | Cada indexer reporta su volumen indexado diariamente al License Manager | #### 6.2 Violaciones y Grace Period * Una violación ocurre cuando el volumen indexado en un día supera la cuota contratada. * Splunk permite **5 violaciones dentro de una ventana móvil de 30 días** antes de degradar funcionalidad. * Al superar el límite: **se bloquea la búsqueda** (no la indexación) hasta regularizar - monitorizar proactivamente. #### 6.3 Comandos y Verificación ```bash # Ver estado y uso actual de licencia /splunk/bin/splunk list licenser-pools /splunk/bin/splunk list licenser-messages # Añadir una nueva licencia /splunk/bin/splunk add licenses /ruta/a/nueva_licencia.lic # Ver violaciones activas /splunk/bin/splunk list licenser-messages | grep -i violation ``` #### 6.4 SPL - Monitorización de Licencia ``` # Uso de licencia por pool (GB/día) index=_internal source=*license_usage.log type=Usage | stats sum(b) as bytes by pool | eval GB = round(bytes/1024/1024/1024, 2) | sort -GB # Proyección de violaciones - volumen últimos 30 días index=_internal source=*license_usage.log type=Usage | timechart span=1d sum(b) as bytes | eval GB = round(bytes/1024/1024/1024, 2) # Volumen por índice (identificar fuente de spike) index=_internal source=*license_usage.log type=Usage earliest=-7d | stats sum(b) as bytes by idx | eval GB = round(bytes/1024/1024/1024, 3) | sort -GB | head 20 # Alerta de licencia al 85% de cuota index=_internal source=*license_usage.log type=Usage earliest=@d | stats sum(b) as daily_bytes | eval daily_GB = round(daily_bytes/1024/1024/1024, 2) | eval quota_GB = | eval pct_used = round(daily_GB / quota_GB * 100, 1) | where pct_used > 85 ``` #### 6.5 Buenas Prácticas * Configurar alerta cuando el uso diario supere el **85% de la cuota** contratada. * Revisar mensualmente la distribución de volumen por cliente/índice para anticipar necesidades de ampliación. * Documentar el volumen por cliente para facturación interna y para anticipar renovaciones de licencia. *** ### 7. Monitoring Console #### 7.1 Qué Es La Monitoring Console (MC, antes DMC) centraliza el estado de salud de todos los roles de la plataforma: indexers, search heads, forwarders, KV Store, clustering. Es el **primer punto de triage** ante cualquier incidente de plataforma. #### 7.2 Configuración ```bash # Habilitar modo distribuido (entornos multi-instancia) Settings → Monitoring Console → Settings → General Setup → Distributed mode ``` ``` # server.conf - anunciar roles de esta instancia a la MC [general] server_roles= indexer, cluster_search_peer ``` #### 7.3 Paneles Clave de Monitoring Console | Panel | Uso operativo | | ------------------------------ | ------------------------------------------------------------------------- | | Indexing Performance: Instance | Detectar indexers con throughput anómalo | | Search Activity: Instance | Búsquedas concurrentes, colas de dispatch, jobs abandonados | | Resource Usage: Machine | CPU/RAM/disco por instancia - correlacionar con incidentes de rendimiento | | Indexer Clustering: Status | RF/SF en tiempo real, buckets pendientes de fixup | | KV Store: Status | Estado de réplica del KV Store en el SHC | | Forwarder Monitoring | Estado y versión de los UF/HF registrados | | License Usage | Consumo de licencia en tiempo real | | Deployment Server Activity | Apps distribuidas y estado de check-in de clientes | #### 7.4 Health Check Automatizado ```bash # Ejecutar el chequeo de salud integrado /splunk/bin/splunk show health --verbose ``` Devuelve un árbol de features (`splunkd`, `indexer`, `search`, `cluster`, `kvstore`) con estado `green`/`yellow`/`red`. #### 7.5 SPL de Monitorización de Rendimiento ``` # CPU y memoria por instancia index=_internal source=*metrics.log group=per_host_thruput earliest=-15m | stats avg(cpu_usage_pct) as avg_cpu_pct, avg(mem_used) as avg_mem_mb by host | eval avg_mem_gb = round(avg_mem_mb/1024, 2) | sort -avg_cpu_pct # Throughput de indexación (KB/s por indexer) index=_internal source=*metrics.log group=thruput host=idx* earliest=-15m | timechart span=1m avg(instantaneous_kbps) by host # Saturación de colas de indexación index=_internal source=*metrics.log group=queue earliest=-30m | eval fill_pct = round(current_size_kb / max_size_kb * 100, 1) | stats avg(fill_pct) as avg_fill, max(fill_pct) as peak_fill by name, host | where peak_fill > 75 | sort -peak_fill ``` *** ### 8. Deployment Server (Update Your Deployment) > **Nota de nomenclatura:** en versiones recientes de Splunk Enterprise, la función anteriormente llamada “Deployment Server / Forwarder Management” se documenta bajo *Update Your Deployment*. El mecanismo subyacente (`serverclass.conf`) no cambia. #### 8.1 Modelo de Funcionamiento ``` [Deployment Server] --push apps/config--> [Deployment Clients (UF/HF)] ``` Cada cliente hace polling periódico (`phoneHomeIntervalInSecs`, default 60s) al DS preguntando si hay apps nuevas o actualizadas para su server class. #### 8.2 `serverclass.conf` en Profundidad ``` # $SPLUNK_HOME/etc/system/local/serverclass.conf # Clase por rango de IP [serverClass:acme_windows_uf] whitelist.0= 10.20.0.0/16 restartSplunkWeb=false restartSplunkd=true [serverClass:acme_windows_uf:app:TA-windows] restartSplunkd=true # Clase por hostname [serverClass:acme_linux_hf] whitelist.0= hf-acme-* machineTypesFilter= linux-x86_64 [serverClass:acme_linux_hf:app:TA-linux_syslog] restartSplunkd=true # Clase por SO [serverClass:all_windows_endpoints] machineTypesFilter= windows-x64 [serverClass:all_windows_endpoints:app:Splunk_TA_windows] restartSplunkd=true stateOnClient= enabled ``` | Directiva | Función | | ----------------------------- | ------------------------------------------------------------------- | | `whitelist.N` / `blacklist.N` | Filtra clientes por IP, hostname o `clientName` | | `restartSplunkd` | Si `true`, reinicia el servicio tras aplicar la app | | `machineTypesFilter` | Filtra por SO (`windows-x64`, `linux-x86_64`) | | `stateOnClient` | `enabled`/`disabled` - controla si la app está activa en el cliente | #### 8.3 Apps de Configuración vs. Apps de Contenido * **Apps de configuración** (TAs con `inputs.conf`/`props.conf`): se distribuyen a UF/HF vía el DS. * **Apps de contenido** (dashboards, alertas): se distribuyen a Search Heads vía el **Deployer del SHC** (§3.3) - son mecanismos separados que a veces se confunden. #### 8.4 Fases de un Deployment 1. Colocar la app en `$SPLUNK_HOME/etc/deployment-apps//` 2. Definir/editar el `serverClass` en `serverclass.conf` 3. Recargar el DS: `splunk reload deploy-server` 4. Verificar que los clientes hicieron check-in y descargaron la app ```bash # Recargar server classes sin reiniciar el DS completo /splunk/bin/splunk reload deploy-server # Ver clientes registrados y su último check-in /splunk/bin/splunk list deploy-clients # Ver qué apps tiene asignadas un cliente específico /splunk/bin/splunk list deploy-clients | grep -A5 ``` #### 8.5 Monitorización del DS ``` # Clientes que no han hecho check-in en >1 hora | rest /services/deployment/server/clients | eval last_check_in_mins = round((now() - phoneHomeTime) / 60, 0) | where last_check_in_mins > 60 | table clientName, ip, last_check_in_mins, splunkVersion | sort -last_check_in_mins # Apps desplegadas por servidor | rest /services/deployment/server/clients | mvexpand applications | table clientName, ip, applications ``` *** ### 9. Administración del Heavy Forwarder #### 9.1 Upgrade de Versión - Procedimiento Completo **Plataformas:** Splunk Heavy Forwarder en Linux (Debian/Ubuntu y RHEL/CentOS)\ **Impacto:** Breve interrupción del servicio Splunk; el reenvío de logs queda pausado durante el reinicio. **Paso 1 - Pre-flight Checks** Documentar el estado actual antes de cualquier cambio: ```bash # Verificar versión actual /splunk/bin/splunk version # Verificar estado del servicio /splunk/bin/splunk status # Verificar KV Store - DEBE retornar "status: ready" antes de continuar /splunk/bin/splunk show kvstore-status # Listar apps instaladas - referencia si alguna se rompe tras el upgrade /splunk/bin/splunk display app ``` > **Bloqueo KV Store:** Si `kvstore-status` no retorna `status: ready`, **NO proceder**. Investigar y resolver el KV Store antes de abrir la ventana de mantenimiento. **Paso 2 - Snapshot de VM** Solicitar snapshot a la infraestructura de virtualización **antes** de cualquier cambio. El snapshot es el único mecanismo de rollback garantizado. * Especificar: nombre/ID de la VM, motivo (upgrade Splunk HF), hora solicitada * **No continuar hasta recibir confirmación escrita del snapshot** **Paso 3 - Transferencia del Paquete de Upgrade** Obtener el `.tgz` desde la [página oficial de releases de Splunk](https://www.splunk.com/en_us/download/previous-releases.html): ```bash # Opción A - Descarga directa en el servidor (requiere acceso a internet) cd /tmp wget -O splunk-9.x.x--Linux-x86_64.tgz \ "-Linux-x86_64.tgz" # Opción B - SCP desde máquina local scp splunk-9.x.x--Linux-x86_64.tgz @:/tmp/ # Verificar que el paquete está presente ls -lh /tmp/splunk-9.x.x--Linux-x86_64.tgz ``` **Paso 4 - Verificar Espacio en Disco** ```bash # Espacio disponible en todas las particiones df -h # Tamaño estimado del paquete extraído (el .tgz es 3-5x más grande al descomprimir) du -sh /tmp/splunk-9.x.x--Linux-x86_64.tgz ``` La extracción requiere **1-2 GB de espacio libre** en la partición de instalación. Si es insuficiente: ```bash # Identificar los directorios más grandes du -sh /* 2>/dev/null | sort -rh | head -20 # Mover paquetes antiguos o archivos temporales mv /paquete-antiguo.tgz /tmp/ ``` > **Precaución:** No mover `/splunk` ni ninguno de sus subdirectorios para liberar espacio - solo archivos estáticos. **Paso 5 - Detener el Servicio Splunk** ```bash sudo /splunk/bin/splunk stop # Confirmar que el servicio se ha detenido /splunk/bin/splunk status ``` **Paso 6 - Realizar el Upgrade** ```bash # Mover el paquete al directorio padre de la instalación mv /tmp/splunk-9.x.x--Linux-x86_64.tgz / # Extraer el nuevo binario sobre la instalación existente cd / sudo tar -xzvf splunk-9.x.x--Linux-x86_64.tgz # Corregir ownership sudo chown -R splunk:splunk /splunk # Iniciar Splunk aceptando la licencia automáticamente sudo -u splunk /splunk/bin/splunk start --accept-license --answer-yes ``` **Paso 7 - Validar KV Store** Inmediatamente después del arranque: ```bash /splunk/bin/splunk show kvstore-status ``` | Resultado | Acción | | ------------------------- | ---------------------------------------- | | `status: ready` | Continuar al Paso 8 | | `status: failed` | Aplicar fix de certificado (ver §10.4.1) | | `status: starting` >5 min | Revisar `mongod.log` (ver §10.4.2) | **Paso 8 - Verificar Ingesta de Logs** ```bash # Errores en splunkd.log tail -f /splunk/var/log/splunk/splunkd.log | grep -E "ERROR|Critical" # Log de DB Connect (si aplica) tail -f /splunk/var/log/splunk/splunk_app_db_connect_server.log # Confirmar nueva versión activa /splunk/bin/splunk version /splunk/bin/splunk status ``` Verificar en SPL que los eventos llegan correctamente: ``` index= earliest=-15m | stats count by host | sort -count ``` **Procedimiento de Rollback** Si el upgrade falla y no puede resolverse dentro de la ventana de mantenimiento: 1. Detener Splunk: `sudo /splunk/bin/splunk stop` 2. Solicitar a infraestructura la reversión de la VM al snapshot del Paso 2 3. Arrancar la instancia revertida: `sudo -u splunk /splunk/bin/splunk start` 4. Confirmar que el reenvío de logs se ha reanudado 5. Documentar el modo de fallo en el ticket para análisis post-mortem *** #### 9.2 Sizing del Heavy Forwarder | Fuentes de Log | EPS (eventos/seg) | vCPU | RAM | Disco (OS + Splunk) | | ------------------- | ----------------- | ---- | ----- | ------------------- | | 1-10 dispositivos | Hasta 500 EPS | 2 | 4 GB | 50 GB | | 10-50 dispositivos | 500-2.000 EPS | 4 | 8 GB | 100 GB | | 50-200 dispositivos | 2.000-10.000 EPS | 8 | 16 GB | 200 GB | | 200+ dispositivos | 10.000+ EPS | 16 | 32 GB | 500 GB | **Cálculo del buffer de disco:** ``` Buffer = EPS × tamaño_medio_evento_bytes × segundos_retención_buffer Ejemplo: 2.000 EPS × 500 bytes × 3.600 seg = 3,6 GB mínimo de buffer ``` El buffer se almacena en `$SPLUNK_HOME/var/lib/splunk/fishbucket` y protege contra pérdida de datos durante interrupciones de red temporales hacia los indexers. **Overhead adicional si corre DB Connect:** | Conexiones DB | RAM adicional | vCPU adicional | | --------------- | ------------- | -------------- | | 1-5 conexiones | +2 GB | +1 vCPU | | 5-20 conexiones | +4 GB | +2 vCPU | | 20+ conexiones | +8 GB | +4 vCPU | #### 9.3 Thresholds de Escalado Horizontal Iniciar revisión de capacidad cuando alguno de los siguientes umbrales se mantenga >30 minutos: | Métrica | Umbral Warning | Umbral Crítico | Acción | | ------------------------------- | -------------------- | ------------------------- | ------------------------------------------------- | | CPU utilización | >70% | >90% | Escalar vCPU o añadir un segundo HF | | RAM utilización | >75% | >90% | Ampliar RAM | | tcpout queue fill | >50% | >80% | Revisar conectividad con indexers; añadir indexer | | caída de EPS (vs. baseline) | >10% | >30% | Investigar bottleneck en pipeline | | Crecimiento del buffer de disco | Tendencia ascendente | >80% capacidad del buffer | Revisar conectividad de red hacia indexers | **Procedimiento para añadir un segundo Heavy Forwarder:** 1. Desplegar nueva VM con OS y versión Splunk idénticos al HF existente 2. Clonar `inputs.conf`, `outputs.conf`, `props.conf`, `transforms.conf` del HF origen 3. Dividir el enrutamiento: asignar la mitad de las fuentes al nuevo HF vía `inputs.conf` 4. Registrar el nuevo HF en el Deployment Server (`serverclass.conf`) 5. Validar el flujo de datos: `index= | stats count by host` - confirmar que las fuentes del nuevo HF aparecen 6. Configurar load balancing en `[tcpout]`: `server = indexer1:9997,indexer2:9997` para failover automático #### 9.4 Referencia de Gestión del Servicio | Operación | Comando | | ---------------------------- | -------------------------------------------------------- | | Iniciar Splunk | `sudo -u splunk /splunk/bin/splunk start` | | Detener Splunk | `sudo /splunk/bin/splunk stop` | | Reiniciar Splunk | `sudo /splunk/bin/splunk restart` | | Ver versión | `/splunk/bin/splunk version` | | Ver estado | `/splunk/bin/splunk status` | | Ver targets de forwarder | `/splunk/bin/splunk list forward-server` | | Estado del KV Store | `/splunk/bin/splunk show kvstore-status` | | Listar apps instaladas | `/splunk/bin/splunk display app` | | Activar inicio en boot | `/splunk/bin/splunk enable boot-start -user splunk` | | Aceptar licencia al arrancar | `/splunk/bin/splunk start --accept-license --answer-yes` | *** ### 10. KV Store en Profundidad #### 10.1 Arquitectura El KV Store es una instancia embebida de MongoDB que corre en cada Search Head. Almacena lookups tipo KV Store, estado de apps (checkpoints de modular inputs), y configuración de ciertas apps (ES, ITSI). #### 9.2 Replicación en Search Head Clustering En un SHC, el KV Store se replica entre los miembros como un **replica set de MongoDB**: un miembro es primario (acepta escrituras) y el resto son secundarios. La elección de primario del KV Store es independiente de la elección de captain del SHC. ```bash # Ver el estado de la réplica del KV Store /splunk/bin/splunk show kvstore-status --verbose ``` #### 9.3 Troubleshooting del KV Store ```bash # Ver logs de replicación grep -i "replset\|rollback" /splunk/var/log/splunk/mongod.log | tail -50 # Forzar resync completo de un miembro con KV Store corrupto/desincronizado /splunk/bin/splunk resync kvstore --auth admin:changeme # Verificar tamaño de colecciones /splunk/bin/splunk rest /services/kvstore/status | grep -i storage ``` ``` # Estado del KV Store via SPL | rest /services/kvstore/status | table status, current.replication.status, current.storageEngine, current.replication.primaryServerAddress ``` #### 9.4 Backup y Restore ```bash # Backup - con Splunk detenido para consistencia /splunk/bin/splunk stop tar -czf kvstore_backup_$(date +%Y%m%d).tar.gz /splunk/var/lib/splunk/kvstore/mongo /splunk/bin/splunk start # Restore - con Splunk detenido /splunk/bin/splunk stop rm -rf /splunk/var/lib/splunk/kvstore/mongo tar -xzf kvstore_backup_20260701.tar.gz -C / /splunk/bin/splunk start ``` > **Importante:** el backup/restore del KV Store se realiza siempre con el servicio detenido para evitar backups inconsistentes. #### 9.5 Colecciones Críticas del KV Store | Colección | App | Propósito | | --------------------- | ----------------------------- | ------------------------------------------ | | `correlationsearches` | SplunkEnterpriseSecuritySuite | Búsquedas de correlación de ES | | `notable` | SplunkEnterpriseSecuritySuite | Notables de ES | | `identities` | SplunkEnterpriseSecuritySuite | Inventario de identidades | | `assets` | SplunkEnterpriseSecuritySuite | Inventario de activos | | Custom lookups KV | Custom apps | Lookups dinámicos (blocklists, thresholds) | *** ### 10. KV Store en Profundidad *(El contenido del KV Store - §9 original - se mantiene. Esta numeración actualizada refleja la inserción de §9 de Administración del Heavy Forwarder. Ver renumeración en Tabla de Contenidos.)* *** ### 11. Workload Management #### 11.1 Qué Resuelve En entornos con múltiples equipos o clientes sobre el mismo Search Head cluster, una búsqueda pesada puede consumir recursos que afectan el SLA de búsqueda de otros. Workload Management (WLM) permite definir **pools de recursos** con límites de CPU/memoria y reglas que asignan cada búsqueda a un pool según su origen. #### 10.2 Conceptos | Concepto | Función | | ----------------- | -------------------------------------------------------------------------------------------- | | **Workload Pool** | Grupo con límites de CPU y memoria (`workload_pools.conf`) | | **Workload Rule** | Condición (usuario, rol, app, tipo) que asigna la búsqueda a un pool (`workload_rules.conf`) | | **Pool default** | Búsquedas que no matchean ninguna regla | #### 10.3 Ejemplo de Configuración ``` # workload_pools.conf [workload_pool:acme_searches] cpu_weight=30 mem_weight=30 default_category= standard [workload_pool:hunting_pool] cpu_weight=20 mem_weight=20 default_category= standard [workload_pool:scheduled_alerts] cpu_weight=50 mem_weight=50 default_category= standard ``` ``` # workload_rules.conf [workload_rule:acme_rule] weight=10 predicate-1= App="search" AND User IN ("acme_analyst1","acme_analyst2") action.category= acme_searches [workload_rule:scheduled_rule] weight=5 predicate-1= SearchType=scheduled action.category= scheduled_alerts ``` #### 10.4 Monitorización WLM ``` # Distribución de búsquedas por pool index=_internal source=*workload_manager.log earliest=-1h | stats count by pool, type | sort -count # Búsquedas rechazadas por límite de pool index=_internal source=*splunkd.log component=wlm action=reject earliest=-1h | stats count by user, app, pool ``` #### 11.5 Cuándo Activar WLM Recomendado cuando un usuario o rol ejecuta búsquedas ad hoc muy pesadas (threat hunting exploratorio, `tstats` sobre rangos grandes) de forma recurrente y se detecta impacto en el SLA de búsqueda de otros usuarios en el mismo SH cluster. También útil para proteger alertas programadas críticas de la competencia con búsquedas interactivas. *** ### 12. Seguridad y Hardening de la Plataforma #### 11.1 TLS Interno Todas las comunicaciones entre componentes deben cifrarse en producción: ``` # server.conf - forzar SSL en comunicaciones [sslConfig] enableSplunkdSSL=true sslPassword= serverCert= /splunk/etc/auth/server.pem sslVersions= tls1.2,tls1.3 cipherSuite= TLSv1.2+HIGH:@STRENGTH ``` ``` # inputs.conf - forzar SSL en el receptor de forwarders [splunktcp-ssl://9997] disabled=0 ``` #### 11.2 Autenticación y Roles * Preferir **SSO/SAML o LDAP** frente a autenticación local para analistas (`authentication.conf`). * Definir roles granulares en `authorize.conf` con capacidades mínimas (principio de menor privilegio). * Nunca asignar `admin` a analistas L1/L2. * Restringir el índice visible por rol según cliente (§1.2), evitando `index=*` en roles de analista. ``` # authorize.conf - rol de analista L1 restrictivo [role_sc_analyst_l1] srchIndexesAllowed= acme_fw;acme_win;acme_edr srchIndexesDefault= acme_fw;acme_win;acme_edr srchDiskQuota=500 srchJobsQuota=5 importRoles= can_delete;user ``` #### 11.3 Capabilities Críticas a Auditar | Capability | Riesgo si se asigna de más | | ----------------------------- | --------------------------------------------- | | `admin_all_objects` | Acceso/edición de cualquier knowledge object | | `edit_user` | Puede escalar privilegios de otros usuarios | | `run_collect` / `output_file` | Puede exfiltrar datos a disco sin restricción | | `rtsearch` | Búsquedas real-time - alto coste de recursos | | `rest_apps_management` | Puede instalar/deshabilitar apps | #### 11.4 Auditoría de Accesos ``` # Usuarios que han accedido a índices que no deberían index=_audit action=search earliest=-7d | rex field=search "index=(?\S+)" | table _time, user, searched_idx, host | where match(searched_idx, "^(acme|contoso|andbank)") # Cambios de configuración realizados (admin_all_objects) index=_audit action=edit OR action=delete earliest=-7d | stats count by user, action, object_type, object_name | sort -count # Intentos de autenticación fallidos en Splunk Web index=_audit action=login attempt=failure earliest=-24h | stats count by user, info, host | sort -count ``` #### 11.5 Checklist de Hardening ``` [ ] TLS habilitado en 9997, 8089 y 8000 con certificados válidos (no autofirmados en producción) [ ] Puerto 8191 (KV Store) no expuesto fuera de la red interna del SH cluster [ ] Puerto 8088 (HEC) no expuesto directamente a internet sin proxy reverso [ ] Autenticación local deshabilitada o restringida a cuentas de servicio/emergencia [ ] Roles de analista sin capability admin_all_objects ni edit_user [ ] Index de auditoría (_audit) habilitado y retenido según política de cumplimiento [ ] Rotación de pass4SymmKey y certificados internos documentada y calendarizada [ ] SAML/LDAP configurado como proveedor de autenticación principal [ ] Usuarios de servicio con contraseñas rotadas y almacenadas en vault [ ] Splunk Web accesible solo desde redes de gestión (no desde internet directamente) ``` *** ### 13. Capacidad y Escalado Avanzado #### 12.1 Guía de Sizing de Indexers | Volumen diario | Indexers recomendados (RF=2) | Disco por indexer (90 días) | | -------------- | ---------------------------- | ------------------------------- | | <50 GB/día | 2 peer nodes | \~2.5 TB | | 50-200 GB/día | 3-4 peer nodes | \~4-8 TB | | 200-500 GB/día | 6-8 peer nodes | \~8-15 TB | | >500 GB/día | 10+ peer nodes | >15 TB (SmartStore recomendado) | > Splunk recomienda **dimensionar los indexers** con al menos 50% de buffer sobre el volumen pico esperado para absorber spikes de ingesta. #### 12.2 Sizing de Search Heads | Usuarios concurrentes | Search Heads recomendados | | --------------------- | ----------------------------- | | <25 | 1 SH (sin cluster) | | 25-100 | 3 SH en cluster | | 100-300 | 5 SH en cluster | | >300 | Escalar horizontalmente + WLM | #### 12.3 Monitorización de Capacidad ``` # Espacio en disco por indexer (alerta si >85%) | rest /services/server/info splunk_server_uri=* | eval disk_used_pct = round((disk_usage / disk_capacity) * 100, 1) | where disk_used_pct > 80 | table splunk_server_uri, disk_used_pct, disk_capacity, disk_usage # Crecimiento de índices (proyectar cuándo se llena el disco) index=_internal source=*metrics.log group=per_index_thruput earliest=-30d | timechart span=1d sum(kbps) as daily_kbps by series | stats avg(daily_kbps) as avg_daily_kbps by series | eval daily_GB = round(avg_daily_kbps * 86400 / 1024 / 1024, 2) | sort -daily_GB ``` *** ### 14. Checklist de Salud de Plataforma Verificación rápida por componente - ejecutar tras cualquier cambio mayor o como parte de la ronda de guardia: ```bash # 1. Salud general de todos los servicios /splunk/bin/splunk show health --verbose # 2. Indexer clustering - RF/SF y fixups /splunk/bin/splunk show cluster-status --verbose # 3. Search Head clustering - captain y estado de miembros /splunk/bin/splunk show shcluster-status # 4. KV Store - replicación y estado de MongoDB /splunk/bin/splunk show kvstore-status --verbose # 5. Licencia - violaciones y uso actual /splunk/bin/splunk list licenser-messages # 6. Deployment Server - clientes activos y desconectados /splunk/bin/splunk list deploy-clients ``` | Chequeo | OK esperado | Acción si falla | | ------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------- | | `show health` | Todas las features en `green` | Revisar feature `yellow`/`red` con `--verbose`, escalar según `Gestión_SIEM.md` §5 | | `cluster-status` | RF/SF cumplidos, 0 buckets pendientes de fixup | Ver §2.5, revisar peer caído | | `shcluster-status` | Captain elegido, todos los miembros `Up` | Ver §3.4, forzar resync si aplica | | `kvstore-status` | `status: ready` en todos los miembros | Ver §9.3 | | `licenser-messages` | Sin warnings de violación | Ver §6.2, revisar volumen por cliente | | Deploy clients | Todos los UF/HF con check-in reciente | Ver §8, verificar conectividad 8089 | #### 13.1 Ronda de Guardia SPL (Ejecutar Diariamente) ``` # Resumen ejecutivo de salud de plataforma | makeresults | eval checks = "Ejecutar los siguientes checks:" | append [ | rest /services/cluster/master/peers | stats count(eval(status!="Up")) as peers_down | eval component = "Indexer Cluster Peers" | eval status = if(peers_down > 0, "NOK" . peers_down . " peers DOWN", "OK") | table component, status ] | append [ | rest /services/kvstore/status | eval kvstatus = current.replication.status | eval component = "KV Store" | eval status = if(kvstatus = "kStandalone" OR kvstatus = "kPrimary" OR kvstatus = "kSecondary", "✅ OK", "⚠️ " . kvstatus) | table component, status ] | table component, status ``` *** ### 15. Referencias Oficiales
TemaReferencia oficial Splunk
Indexer ClusteringManage Indexers and Indexer Clusters
Search Head ClusteringDistributed Deployment Manual → SHC
SmartStoreSmartStore
Distributed SearchConfigure Distributed Search
Gestión de LicenciasAdmin Manual → Licenses
Monitoring ConsoleMonitoring Console Overview
Deployment ServerUpdate Your Deployment
KV StoreAdminister the App Key Value Store
Workload ManagementWorkload Management
HardeningSecuring Splunk Enterprise
UpgradeUpgrade Splunk Enterprise
Capacity PlanningCapacity Planning
**Referencias entre documentos:** * `Integraciones.md` §7, §8, §9 - TAs y forwarders desplegados vía DS * `Dashboards.md` §14 - dashboards de salud de plataforma * `SPL.md` / `Documentación Completa de SPL.md` - troubleshooting de búsquedas y performance