<color #ffc90e>Noen eksempler på rsync, dette gjelder ren filkopi</color>

rsync -Hav /opt/splunk/etc /backupmappe/
rsync -Hav -e ssh brukernavn@splunkserver:/opt/splunk/etc /lokalt/mål/

<color #ffc90e>Alternativt å zippe den.</color>

zip -r opt_splunk_etc_hostnavn.zip /opt/splunk/etc  /filbane/med_mye_plass/

<color #ffc90e>Kvstore backup</color>
KvStore krever en egen backup løsning som Splunk må gjøre.Og den blir lagret i <color #ffc90e>/opt/splunk/var/lib/splunk/kvstorebackup.</color>

/opt/splunk/bin/splunk backup kvstore 

<color #ffc90e>Splunk diag fil</color>
Normalt vil den bli lagret i <color #ffc90e>/opt/splunk/etc/var/run/splunk/splunk_diag_logs/</color>
Eksemplet viser også hvordan du kan overstyre filstien.

/opt/splunk/bin/splunk diag 
/opt/splunk/bin/splunk diag --target /din/egne/sti/

Å lage en Diag vil også lage en komplett kopi av etc-mappen uten SSL filer.

Når man gjør søk og schedulederte søk, så vil arbeide være lagret i kvstore. Og et søkehode vil dele disse dataene med andre søkehoder i samme cluster, og dele dette med indexere.
Om en benytter seg av workload management, så vil den også bruke kvstore i stor del for å samle data mellom søkehodene.
Så en kan slette innholdet i en kvstore, og starte opp splunk og den vil virke. Kvstore har ikke noe med lagrede data i en index å gjøre.
Dette er den skitne måten å gjøre det på, men noen gang er det eneste måten en kan gjøre det på.
En grov og dårlig måte:

1. <color #ffc90e>Stop Splunk</color>
   1. /opt/splunk/bin/splunk stop
2. <color #ffc90e>Tøm kvstore</color>
   1. /opt/splunk/bin/splunk clean kvstore –local
3. <color #ffc90e>Start Splunk igjen</color>
   1. opt/splunk/bin/splunk start

En bedre ryddigere måte er denne:

1. <color #ffc90e>Stop Splunk</color>
   1. /opt/splunk/bin/splunk stop
2. <color #ffc90e>Backup the folder</color>
   1. /opt/splunk/var/lib/splunk/kvstore/mongo and move the backup somewhere outside Splunk.
3. <color #ffc90e>Invoke</color>
   1. /opt/splunk/bin/splunk clean kvstore –cluster
4. <color #ffc90e>Slett mappen og filen</color>
   1. /opt/splunk/var/lib/splunk/kvstore/mongo/journal
   2. /opt/splunk/var/lib/splunk/kvstore/mongo/mongod.lock
5. <color #ffc90e>Invoke</color>
   1. /opt/splunk/bin/mongod –dbpath /opt/splunk/va/r/lib/splunkkvstore/mongo –port=8191 —repair
6. <color #ffc90e>Så kan du starter Splunk igjen</color>
   1. /opt/splunk/bin/splunk start

<color #ffc90e>Inputs.conf-filen</color> er selve oppstartsfilen som definerer hvilken fil eller skript Splunk skal hente, lese eller kjøre.
Den har mange muligheter, og jeg vil forsøke å liste noen gode eksempler.

<color #ffc90e>Kildevurdering:</color>
Du kan også bruke «props.conf» og «transforms.conf» sammen med «inputs.conf» for mer avansert databehandling
som ekstrahering og transformasjon av data før indeksering.
Husk at konfigurasjonen avhenger av datakildene og kravene dine. Du bør tilpasse «inputs.conf» i samsvar med de spesifikke kravene for datainnsamlingen og indekseringen du trenger for din Splunk-implementering.

<color #ffc90e>Loggfiler:</color>
Du kan konfigurere Splunk til å overvåke loggfiler og indeksere data fra dem.
Dette vil overvåke filen «/var/log/app.log», indeksere dataene i indeksen «app_logs» og tilordne dem en
spesiell sourcetype «application_log». For eksempel:

    [monitor:///var/log/app.log]
    disabled = false
    index = app_logs
    sourcetype = application_log

Eksempelet inkluderer en rekke filtre for å filtrere innsamlede data. Du kan tilpasse disse filtrene etter dine spesifikke behov:

[monitor:///path/to/log1.log]
disabled = false
index = log_data
sourcetype = custom_log
host = webserver
blacklist = \.(jpg|png|gif)$
whitelist = ^/pages/
crcSalt = <SOURCE>
crcSalt = <SOURCE>_<HOST>
 
[monitor:///path/to/log2.log]
disabled = false
index = log_data
sourcetype = custom_log
host = appserver
whitelist = ^/api/
whitelist = ^/admin/
maxDaysAgo = 7

I dette eksempelet har vi konfigurert to overvåkede filer, log1.log og log2.log. Vi har brukt forskjellige filtre for hver kilde:

<color #ffc90e>host</color>
Angir vertens navn (vertshost) for hendelsene. Dette kan brukes til å filtrere hendelser fra en bestemt kilde.

<color #ffc90e>blacklist</color>
Filtret ekskluderer hendelser som samsvarer med det gitte regex-mønsteret. I dette tilfellet ekskluderer det bildefiler (jpg, png, gif) fra innsamlingen.

<color #ffc90e>whitelist</color>
Filtret inkluderer bare hendelser som samsvarer med det gitte regex-mønsteret. I dette tilfellet inkluderer det bare hendelser som starter med «/pages/» for log1.log og hendelser som starter med «/api/» eller «/admin/» for log2.log.

<color #ffc90e>crcSalt</color>
Angir en «salt» for CRC-beregning. Dette er nyttig for å unngå konflikter og endringer i CRC-verdien hvis kilden eller verten endres.

<color #ffc90e>maxDaysAgo</color>
Begrenser datavolumet ved å ekskludere hendelser som er eldre enn det spesifiserte antall dager. Dette hjelper deg med å unngå overveldende indekseringen med gamle data.
Du kan tilpasse disse filterkonfigurasjonene i henhold til dine krav for datafiltrering og innsamling. Filtrene gir deg fin kontroll over hvilke hendelser som skal inkluderes eller ekskluderes fra innsamlingen basert på forskjellige attributter, for eksempel kilden, verten, filtypen, banen og datoen.

Her er et eksempel på hvordan du kan bruke KV_MODE, KV_DELIMITER, FIELDALIAS, og REGEX for å dekode data i et bestemt hendelsesformat (CSV) og deretter fjerne eller rense unødvendige felt:
<color #ffc90e>Eksempellogg i CSV-format (data.csv)</color>

Timestamp,Username,Action,Result
2023-10-13 10:00:00,Alice,Login,Success
2023-10-13 11:15:00,Bob,Update,Failed

<color #ffc90e>Konfigurasjoner i inputs.conf for å dekode CSV-data:</color>

[monitor:///path/to/data.csv]
disabled = false
index = log_data
sourcetype = csv_data
KV_MODE = csv
KV_DELIMITER = ,
NO_BINARY_CHECK = true

I dette eksempelet bruker vi KV_MODE = csv og KV_DELIMITER = , for å dekode dataene som CSV. Vi bruker også NO_BINARY_CHECK = true for å unngå feilmeldinger om binærdata.

<color #ffc90e>Konfigurasjoner i transforms.conf for å fjerne unødvendige felt:</color>

[remove_unwanted_fields]
REGEX = (?:Timestamp|Result),[^,]*,
DEST_KEY = queue
FORMAT = nullQueue
 
[alias_fields]
FIELDALIAS-action = Action AS EventAction

Her bruker vi <color #ffc90e>transforms.conf</color> til å konfigurere to transformasjoner:

remove_unwanted_fields fjerner feltene <color #ffc90e>«Timestamp»</color> og <color #ffc90e>«Result»</color> ved å sende dem til <color #ffc90e>nullQueue.</color> Dette filtrerer ut unødvendige felt.

alias_fields oppretter en alias for feltet <color #ffc90e>«Action»</color> ved å omdøpe det til <color #ffc90e>«EventAction.»</color> Dette gir feltet en ny navnidentitet for bedre lesbarhet eller konsistens i dataene.

Når du har konfigurert disse filtrene, vil Splunk dekode dataene i CSV-format og rense dem ved å fjerne unødvendige felt og opprette aliaser for andre felt, slik at du får en mer brukervennlig visning av dataene i Splunk. Dette kan være nyttig når du ønsker å tilpasse dataene til din brukssak eller forenkle deres presentasjon.

Overvåke flere filtyper med én konfigurasjon: Du kan overvåke flere filtyper i en enkelt mappe ved å bruke komma (,) som skilletegn.
Dette vil overvåke både .log- og .txt-filer i mappen og indeksere dem med en felles sourcetype og indeks.

[monitor:///path/to/logs/*.log,/path/to/logs/*.txt]
disabled = false
index = mixed_logs
sourcetype = mixed_log

Her er et eksempel på hvordan du kan bruke /…/ i en filbane i inputs.conf for å overvåke alle undermapper:

[monitor:///path/to/logs/.../]
disabled = false
index = log_files
sourcetype = log

Hvis du vil overvåke spesifikke filtyper i rekursive mapper, for eksempel alle .txt-filer, kan du bruke wildcards som følger:

[monitor:///path/to/logs/*.txt]
disabled = false
index = log_files
sourcetype = log

Overvåke alle loggfiler i undermapper og undermapper til undermapper: Hvis du ønsker å overvåke alle loggfiler i rekursive mapper, inkludert undermapper og undermapper til undermapper, kan du bruke /…/ flere ganger for å indikere rekursiv overvåking av mapper:

[monitor:///path/to/logs/.../.../]
disabled = false
index = log_files
sourcetype = log

Overvåke alle filer i hjemmemappen for en bruker.
Dette vil overvåke alle filer og undermapper i hjemmemappen til brukeren og indeksere dem med angitt indeks og sourcetype.
Du kan overvåke alle filer i hjemmemappen for en bestemt bruker ved å bruke en tilsvarende bane:

[monitor://~/]
disabled = false
index = user_home
sourcetype = user_logs

Splunk kan også hente data fra eksterne API-er. Dette kan være nyttig for å hente data fra tredjepartsapplikasjoner eller tjenester.

[https://bf-esb-internet.edb.com/secesb/rest/era-dsop/v1/4076]
disabled = false
index = api_data
sourcetype = api_event
interval = 300

Eksemplet viser hvordan vi kan konfigurere inputs.conf, props.conf og transforms.conf for å behandle en loggfil som inneholder både vanlige data og potensielt sensitive data ved hjelp av en sinkhole:

inputs.conf for å overvåke loggfilen og sende dataene til Splunk:

<color #ffc90e>inputs.conf</color>
Dette vil overvåke loggfilen «logfile.log» og indeksere den med indeksen «log_data» og sourcetype «your_log.»

[monitor:///path/to/your/logfile.log]
disabled = false
index = log_data
sourcetype = your_log

<color #ffc90e>props.conf</color>
Her har vi definert et transformasjonsnavn «sinkhole» som vi vil bruke for å sende potensielt sensitive data til sinkhole. Dette vil se etter data som skal behandles i transforms.conf.

[your_log]
TRANSFORMS-sinkhole = sinkhole

<color #ffc90e>transforms.conf</color>
I dette eksempelet bruker vi en REGEX for å identifisere linjer som inneholder «Sensitive data:» og deretter bruke nullQueue for å sende dataene til en sinkhole ved å sette queue til nullQueue. Dette vil forhindre indeksering av disse linjene. Når du har satt opp disse konfigurasjonene, vil Splunk overvåke loggfilen, indeksere vanlige data og identifisere linjer som inneholder «Sensitive data:» som potensielt sensitive data. Disse potensielt sensitive dataene blir da sendt til sinkhole og ikke indeksert i Splunk.
Merk at dette er et enkelt eksempel, og du kan tilpasse REGEX-mønsteret og behandlingen i transforms.conf etter dine spesifikke behov for håndtering av sensitive data.

[sinkhole]
REGEX = .*Sensitive data: (.*)
DEST_KEY = queue
FORMAT = nullQueue

Splunk kan lytte på nettverksporter for å fange inn datastrømmer, som syslog- eller Windows Event Log-hendelser som sendes over nettverket.

[tcp://0.0.0.0:514]
disabled = false
index = network_logs
sourcetype = syslog
connection_host = dns

<color #ffc90e>Nettverkssniffer:</color>
Dette vil fange nettverkstrafikken fra grensesnittet «eth0» og indeksere den i indeksen «network_traffic» med sourcetype «packet_capture».
Hvis du vil fange nettverkstrafikk, kan du bruke netmon-typen:

[netmon://my_capture]
disabled = false
index = network_traffic
sourcetype = packet_capture
interface = eth0

<color #ffc90e>Logg eksempel:</color>
Dette eksemplet viser hvordan vi kan bruke regex for å maskere brukernavnet i en logg som vi henter inn i splunk.
Den viser alle filene som krever og som er nødvendig for at maskering skal fungere.

2023-10-13 10:30: User Alice logged in.
2023-10-13 11:45: User Bob updated a document.
2023-10-13 12:15: User Carol logged in.

[monitor:///path/to/sample.log]
disabled = false
index = sample_logs
sourcetype = sample_log

TRANSFORMS-usermask = usermask

[usermask]
REGEX = (\d{4}-\d{2}-\d{2} \d{2}:\d{2}):\sUser (\w+)
FORMAT = $1: User xxx

2023-10-13 10:30: User xxx logged in.
2023-10-13 11:45: User xxx updated a document.
2023-10-13 12:15: User xxx logged in.

Eksempel på hvordan du kan kombinere data fra to forskjellige kilder, en Windows påloggingslogg og en Netflow-logg, og deretter legge til brukernavn fra Windows-påloggingsloggen til Netflow-loggen ved hjelp av konfigurasjoner i inputs.conf, props.conf, og transforms.conf.

2023-10-13 10:00: User Alice logged in from IP 192.168.1.10.
2023-10-13 11:15: User Bob logged in from IP 192.168.1.20.

2023-10-13 10:05: Packet from IP 192.168.1.10 to IP 8.8.8.8.
2023-10-13 11:20: Packet from IP 192.168.1.20 to IP 8.8.8.8.

<color #ffc90e>inputs.conf for å overvåke begge loggene</color>
Her overvåker vi begge loggene og angir forskjellige sourcetypes for hver.

[monitor:///path/to/log1.log]
disabled = false
index = log_data
sourcetype = windows_log
 
[monitor:///path/to/log2.log]
disabled = false
index = log_data
sourcetype = netflow_log

<color #ffc90e>props.conf for å kombinere dataene</color>

[windows_log]
REPORT-windows_user = extract_windows_user
 
[netflow_log]
REPORT-windows_user = extract_windows_user
 
[log_data]
TRANSFORMS-add_username = combine_logs

<color #ffc90e>transforms.conf for å kombinere dataene</color>

[extract_windows_user]
REGEX = User (\w+) logged in from IP (\d+\.\d+\.\d+\.\d+)
FORMAT = user::$1 ip::$2
 
[combine_logs]
REGEX = (\S+) (\S+): (\S+) from IP (\d+\.\d+\.\d+\.\d+).
SOURCE_KEY = _raw
DEST_KEY = _raw
FORMAT = $1::$2 $3::$4

Den første transformasjonen <color #ffc90e>extract_windows_user</color> brukes for å hente brukernavn og IP fra Windows påloggingsloggen.

Den andre transformasjonen <color #ffc90e>combine_logs</color> brukes for å kombinere data fra de to loggene basert på IP-adressen. Den legger også til brukernavnet fra Windows påloggingsloggen til Netflow-loggen.

Når du har konfigurert disse filene, vil Splunk kombinere dataene fra de to kildene basert på IP-adressen, og resultatet vil inneholde brukernavn fra Windows-påloggingsloggen i Netflow-hendelsene. Du kan tilpasse REGEX-mønstrene og feltene i transformasjonene etter behov og dine spesifikke datakilder.

Her er et komplett eksempel med en loggdatafil, inputs.conf, props.conf, og transforms.conf for å konvertere loggdata til Splunk Enterprise Security CIM-format

<color #ffc90e>Loggdatafil (loggdata.txt)</color>

2023-10-13 14:25:10 4624 Logon
2023-10-13 14:30:15 4776 Logoff
2023-10-13 14:35:20 5156 Firewall
2023-10-13 14:40:25 4624 Logon
2023-10-13 14:45:30 4776 Logoff
2023-10-13 14:50:35 5156 Firewall
2023-10-13 14:55:40 4624 Logon
2023-10-13 15:00:45 4776 Logoff
2023-10-13 15:05:50 5156 Firewall

[monitor:///path/to/loggdata.txt]
disabled = false
index = cim_index
sourcetype = cim_data

SHOULD_LINEMERGE = false
TRANSFORMS-cim = set_cim_fields

<color #ffc90e>Konfigurasjoner i transforms.conf for CIM-formatkonvertering:</color>

[set_cim_fields]
REGEX = (?m)^(?<timestamp>\S+) (?<event_id>\d+) (?<event_type>\S+).*?
FORMAT = cim::$1::$2::$3

Nå, når du har konfigurert dette, vil loggdataene i loggdata.txt overvåkes, konverteres til CIM-format og indekseres i indeksen cim_index med sourcetypen cim_data. Du kan tilpasse indeksen, sourcetypen og andre innstillinger etter behov.

For å se hendelsesdataene i CIM-format, kan du søke etter dem ved hjelp av Splunk-søk og dra nytte av CIM-spesifikke felt som «timestamp,» «event_id,» og «event_type.»

Dette eksempelet gir deg en enkel måte å konvertere og indeksere loggdata i Splunk Enterprise Security CIM-format. Du kan deretter bruke Splunk Enterprise Security eller andre applikasjoner for sikkerhetsovervåking for å analysere og utføre handlinger basert på disse dataene.

If you want to add a field to all events, regardless of the sourcetype, you can apply this field addition directly to the default stanza in the props.conf file. This will apply the field addition to all incoming events without needing to specify a sourcetype.

Here's how you can achieve this:

Edit the props.conf file on your Heavy Forwarders.
<color #ffc90e>Add the following stanza to props.conf</color>

[_]
TRANSFORMS-sethf = set_heavyforwarder_field

<color #ffc90e>In the above configuration:</color>
[_] is the default stanza that applies to all events.

<color #ffc90e>set_heavyforwarder_field</color>
Is the name of the transform that we'll define in the next step.
Create a transforms.conf file if you don't already have one, and add the following stanza:

[set_heavyforwarder_field]
REGEX = .
DEST_KEY = _MetaData:HF_Name
FORMAT = HeavyForwarderName

In this configuration:

<color #ffc90e>set_heavyforwarder_field</color> is the transform name that matches the one in props.conf.
HeavyForwarderName should be replaced with the name of the Heavy Forwarder (e.g., HF1, HF2, etc.)
that you want to associate with these events.
Restart the Splunk instance on the Heavy Forwarders to apply the configuration changes.
With this configuration, the HeavyForwarderName field will be added to all incoming events, regardless of their sourcetype.
You can then use this field in your searches to identify the source Heavy Forwarder for each event.

Her er et eksempel med loggdata før og etter data-transformasjon ved bruk av SEDCMD i props.conf for å maskere sensitive data. Vi vil bruke en loggdatafil som inneholder brukernavn og passord, og deretter maskere passordene før de indekseres.

<color #ffc90e>Loggdatafil (loggdata.txt)</color>

2023-10-13 14:25:10 - Bruker: alice, Passord: hemmelig123
2023-10-13 14:30:15 - Bruker: bob, Passord: superhemmelig456
2023-10-13 14:35:20 - Bruker: carol, Passord: topphemmelig789

<color #ffc90e>Konfigurasjoner i props.conf for data-transformasjon</color>

[data_transform]
SEDCMD-password = s/Passord: [^,]*/Passord: maskert/

I <color #ffc90e>props.conf</color> har vi definert en konfigurasjon med SEDCMD-password, som bruker et regulært uttrykk for å erstatte passordene med stjerner (**). Dette maskerer passordene før dataene sendes videre til indeksering.

Når du har konfigurert dette, vil loggdataene bli transformert før de indekseres, og passordene vil bli erstattet med 3 xxx. Her er hvordan loggdataene vil se ut etter transformasjonen.
<color #ffc90e>Loggdata etter data-transformasjon</color>

2023-10-13 14:25:10 - Bruker: alice, Passord: xxx
2023-10-13 14:30:15 - Bruker: bob, Passord: xxx
2023-10-13 14:35:20 - Bruker: carol, Passord: xxx

Såkaldt <color #ffc90e>«dehashing»</color> eller <color #ffc90e>«unhashing»,</color> for å konvertere maskerte passord tilbake til deres opprinnelige form hvis du har en reverseringsalgoritme og nødvendige data for å gjøre det. Dette kan være nyttig for gjenoppretting av passord hvis det er nødvendig for noen grunner.
Hvis du har spesielle krav for passordhåndtering, kan det være lurt å konsultere med en sikkerhetsekspert eller juridisk rådgiver for å sikre at du gjør det i samsvar med gjeldende lover og beste praksis.</color>svar med gjeldende lover og beste praksis.

Her er et eksempel med loggdata som inneholder sensitiv informasjon (f.eks., kredittkortnumre) og demonstrerer maskering (kryptering) av data i Splunk, samt muligheten til å dekryptere data ved behov. Vi vil demonstrere hvordan du kan maskere (kryptere) kredittkortnumrene i loggdataene og deretter dekryptere dem ved behov. Dette gjøres ved hjelp av SEDCMD i props.conf.
<color #ffc90e>Loggdatafil (loggdata.txt)</color>

2023-10-13 14:25:10 - Bruker: alice, Kredittkort: 1234-5678-9012-3456
2023-10-13 14:30:15 - Bruker: bob, Kredittkort: 9876-5432-1098-7654
2023-10-13 14:35:20 - Bruker: carol, Kredittkort: 5678-1234-3456-9012

<color #ffc90e>Konfigurasjoner i props.conf for maskering og dekryptering</color>

SEDCMD-mask_credit_card = s/Kredittkort: \d{4}-\d{4}-\d{4}-\d{4}/Kredittkort: xxx/
SEDCMD-decrypt_credit_card = s/Kredittkort: \*{12}/Kredittkort: 1234-5678-9012-3456/

<color #ffc90e>I props.conf har vi definert to konfigurasjoner</color>
SEDCMD-mask_credit_card for å maskere kredittkortnumrene og SEDCMD-decrypt_credit_card for å dekryptere dem. Konfigurasjonen SEDCMD-mask_credit_card bruker et regulært uttrykk for å erstatte kredittkortnumrene med xxx eventuelt du kan bruke stjerner som stemmer med antall nummer om dette ikke fungerer, mens SEDCMD-decrypt_credit_card reverserer operasjonen og gjenoppretter de originale kredittkortnumrene.

<color #ffc90e>Søk for å maskere kredittkortnumre</color>
Nå kan vi søke etter dataene og bruke maskering og dekryptering i Splunk. Her er noen eksempler på søk.

sourcetype=masked_data | eval MaskedCC = coalesce(mvindex(replace("Kredittkort: xxx"),0,"Kredittkort: ")) | table _time, Bruker, MaskedCC

<color #ffc90e>Søk for å dekryptere kredittkortnumre</color>

sourcetype=masked_data | eval DecryptedCC = coalesce(mvindex(replace("Kredittkort: 1234-5678-9012-3456"),0,"Kredittkort: ")) | table _time, Bruker, DecryptedCC

Disse søkene vil vise loggdataene med maskerte <color #ffc90e>krypterte</color> og <color #ffc90e>dekrypterte</color> kredittkortnumre, avhengig av hvilket søk du kjører.

Merk at dette eksempelet er en enkel illustrasjon av maskering og dekryptering i Splunk. I en reell implementasjon må du sørge for at sikkerheten er ivaretatt og at nøkler og prosesser for dekryptering er riktig beskyttet. Sensitive data som kredittkortnumre bør behandles med forsiktighet og i samsvar med personvernlover.

<color #ffc90e>Stanza for load balansing</color>
Dette vil sende data til en gruppe som heter load_balancer som inneholder 3 servere.

[tcpout]
defaultGroup = load_balancer
 
[tcpout:load_balancer]
server = canada_indexer1:9997, london_indexer1:9997, oslo_indexer1:9997

Anta at du har en Heavy Forwarder som samler inn loggdata fra forskjellige kilder og ønsker å sende kopier av dataene til både Splunk-indeksservere og en SIEM-løsning.

<color #ffc90e>Konfigurasjon i outputs.conf på Heavy Forwarder</color>

[tcpout]
defaultGroup = my_indexers
 
[tcpout:my_indexers]
server = indexer1:9997, indexer2:9997
 
[tcpout:siem]
server = siem_server:514

I dette eksempelet har vi definert to servergrupper i outputs.conf. my_indexers inneholder IP-adressene og portene til Splunk-indeksserverne, mens siem inneholder informasjonen for SIEM-serveren.

Når Heavy Forwarder samler inn loggdata, sender den kopier av dataene til både Splunk-indeksserverne og SIEM-serveren samtidig. Du trenger ikke å utføre noen spesielle søk for å oppnå dette - det er en del av konfigurasjonen.

Dette sikrer at loggdataene dine blir indeksert i Splunk for sikkerhetsinformasjon og hendelsesbehandling og sendt til SIEM-løsningen for mer omfattende sikkerhetsanalyse og rapportering.

Merk at konfigurasjonen kan variere avhengig av SIEM-løsningen du bruker, da ulike SIEM-løsninger kan kreve forskjellige formater og protokoller for dataintegrasjon. Du må tilpasse konfigurasjonen i samsvar med SIEM-leverandørens krav.

Eksempel på Loggdata:

<color #ffc90e>La oss anta at du har følgende loggdata i en fil som inneholder sikkerhetshendelser</color>

[2023-10-13 10:00:00] Source IP: 192.168.1.100, Severity: high, Event: Unauthorized access
[2023-10-13 10:15:00] Source IP: 192.168.1.101, Severity: low, Event: Failed login attempt
[2023-10-13 10:30:00] Source IP: 192.168.1.102, Severity: high, Event: Malware detection

I alerts.conf kan du definere varslingen som skal utløses basert på kriteriene.
I dette eksemplet ønsker vi å varsle på hendelser med høy alvorlighetsgrad (Severity: high)
<color #ffc90e>alerts.conf-konfigurasjon</color>

[my_security_alert]
condition = (sourcetype="security_logs") AND (severity="high")
action.email = security-team@example.com

For å indeksere loggdataene må du konfigurere en kilde i inputs.conf.
Her antar vi at loggdataene er i en fil kalt security.log.
<color #ffc90e>inputs.conf-konfigurasjon</color>

[monitor:///path/to/security.log]
sourcetype = security_logs
props.conf-konfigurasjon:

Her er en enkel eksempelkonfigurasjon for å angi sourcetype og transformere logghendelsene.
<color #ffc90e>Hvis du ønsker å endre eller formatere dataene før indeksering, kan du bruke props.conf</color>

[security_logs]
TRANSFORMS-set_sourcetype = set_sourcetype

I transforms.conf kan du definere en transformasjon for å tilordne riktig sourcetype.
<color #ffc90e>transforms.conf-konfigurasjon</color>

[set_sourcetype]
REGEX = sourcetype = (.+)
DEST_KEY = MetaData:Sourcetype
FORMAT = sourcetype::$1

Når du har satt opp konfigurasjonen, vil Splunk indeksere loggdataene og utløse varselet når det oppdages en hendelse med høy alvorlighetsgrad. Varselet vil bli sendt til e-postadressen security-team@example.com.
Merk at dette er et grunnleggende eksempel, og i en produksjonssetting kan du tilpasse konfigurasjonen, inkludert handlinger, kriterier og e-postinnstillinger, i henhold til organisasjonens behov.

Dette søket vil vise køstørrelsen på HF1, HF2 og HF3 i løpet av de siste 4 timene.
<color #ffc90e>Søk for å vise Forwarder køen på Heavy Forwarders over 4 timer</color>

index=_internal source="*metrics.log" host=(hf1 OR hf2 OR hf3) metric_name="queueSize" 
| timechart span=1h max(current) as "Forwarder Queue" by host

Dette søket vil vise køstørrelsen for søkerkøen, forberedelseskøen og distribusjonskøen på SH1, SH2 og SH3 i løpet av de siste 4 timene.
<color #ffc90e>Søk for å vise søkerkøen, forberedelseskøen og distribusjonskøen på Søkehodeklyngen over 4 timer</color>

index=_internal source="*metrics.log" host=(sh1 OR sh2 OR sh3) metric_name="queueSize" (queue="search_queue" OR queue="prepsearch_queue" OR queue="distribute_queue") 
| timechart span=1h max(current) as "Search Queue", max(current) as "Prep Search Queue", max(current) as "Distribute Queue" by host

Dette søket vil vise størrelsen på Parsing Queue og dens kilde (host).
<color #ffc90e>Søk for å vise Parsing Queue og dens kilde</color>

index=_internal source="*metrics.log" metric_name="queueSize" queue="parsingQueue" 
| stats max(current) as "Parsing Queue" by host

Dette søket vil vise HEC køstørrelsen på alle dine indexere (idx1 til idx14) i løpet av de siste 4 timene.
<color #ffc90e>Søk for å vise HEC køen på alle indexerne over 4 timer</color>

index=_internal source="*metrics.log" host=(idx1 OR idx2 OR idx3 OR idx4 OR idx5 OR idx6 OR idx7 OR idx8 OR idx9 OR idx10 OR idx11 OR idx12 OR idx13 OR idx14) metric_name="queueSize" queue="hec_queue" 
| timechart span=1h max(current) as "HEC Queue" by host

Du kan tilpasse disse søkene etter behov, for eksempel ved å legge til flere host- eller queue-

<color #ffc90e>Søkehodekøer</color>
For å overvåke søkerkøen, forberedelseskøen og distribusjonskøen på søkehodene dine, kan du bruke følgende søk
Dette søket gir deg en timechart som viser størrelsen på hver kø for SH1, SH2 og SH3.
<color #ffc90e>Søk for å vise Forwarder køen på Heavy Forwarders over 4 timer</color>

index=_internal source="*metrics.log" host=(sh1 OR sh2 OR sh3) metric_name="queueSize" (queue="search_queue" OR queue="prepsearch_queue" OR queue="distribute_queue") 
| timechart span=1h max(current) by host

<color #ffc90e>Cluster-spesifikke køer</color>
For å overvåke replikeringskøer og indekseringskøer i klyngene (cluster1, cluster2 og siem-data), kan du bruke følgende søk
Dette søket gir deg en timechart som viser størrelsen på replikerings- og indekseringskøene i klyngene dine.

index=_internal source="*metrics.log" host=(cluster1 OR cluster2 OR siem-data) metric_name="queueSize" (queue="replication_queue" OR queue="index_queue") 
| timechart span=1h max(current) by host

<color #ffc90e>Logg og varsling</color>
For å lage logger og varslinger basert på ytelsesmålinger og avvik fra terskler, kan du bruke Splunks varslingssystem.
Her er et eksempel på hvordan du kan konfigurere en varsling basert på en køstørrelse.

<color #ffc90e>Gå til Splunk Web,</color> og velg <color #ffc90e>«Settings»</color> → <color #ffc90e>«Alerts.»</color> Klikk på <color #ffc90e>«New Alert»</color> for å opprette en ny varsling.
Angi en terskel for køstørrelsen, for eksempel <color #ffc90e>«greater than 1000.»</color> Konfigurer varslingskanalen (f.eks. e-postvarsling) og mottakeradressen. Lagre varslingen, og den vil generere varsler når køstørrelsen overskrider terskelen. Du kan gjenta denne prosessen for andre ytelsesmålinger og køer. Definer søket som overvåker køstørrelsen, for eksempel

index=_internal source="*metrics.log" metric_name="queueSize" queue="search_queue" host=sh1

<color #ffc90e>Heavy Forwarder-køer</color>
For å overvåke Heavy Forwarders, inkludert videresendingskøen og eventuelle transformasjonskøer, kan du bruke lignende søk som for søkehodekøene. Her er et eksempel: Dette søket gir deg en timechart som viser størrelsen på videresendingskøen og eventuelle transformasjonskøer på HF1, HF2 og HF3

index=_internal source="*metrics.log" host=(hf1 OR hf2 OR hf3) metric_name="queueSize" (queue="forwarder_queue" OR queue="transform_queue") 
| timechart span=1h max(current) by host

In order to set up Search Head Clustering, you need a Deployer (Splunk Enterprise Instance) and two or more Search Heads (Splunk Enterprise Instances).

• Install Splunk Enterprise Edition on your instance.
• Enable Splunk to start on boot (optional instruction): /opt/splunk/bin/splunk enable boot-start
• Start Splunk: /opt/splunk/bin/splunk start.
• Before setting up SH cluster, enable HTTPS.
• Go to Settings > Server Settings > General Settings.
• Restart Splunk.

- In the Deployer, edit ''/opt/splunk/etc/system/local/server.conf'' as follows:
    ```
    [shclustering]
    pass4SymmKey = password
    shcluster_label = shcluster1
    ```

- In the Search Head Peer Node, execute the following command:

  ./splunk init shcluster-config -auth <username>:<password> -mgmt_uri <URI of your search head member>:<management_port> -replication_port <replication_port> -replication_factor <n> -conf_deploy_fetch_url <URL deployer>:<management_port> -secret <security_key> -shcluster_label <label>

Søkehode 1

./splunk init shcluster-config -auth admin:splunk1234 -mgmt_uri https://10.128.0.16:8089 -replication_port 34567 -replication_factor 3 -conf_deploy_fetch_url https://10.128.0.17:8089 -secret shcluster -shcluster_label shcluster1

Søkehode 2

    ./splunk init shcluster-config -auth admin:splunk1234 -mgmt_uri https://10.166.0.2:8089 -replication_port 34567 -replication_factor 3 -conf_deploy_fetch_url https://10.128.0.17:8089 -secret shcluster -shcluster_label shcluster1

Søkehode 3

./splunk init shcluster-config -auth admin:splunk1234 -mgmt_uri https://10.202.0.2:8089 -replication_port 34567 -replication_factor 3 -conf_deploy_fetch_url https://10.128.0.17:8089 -secret shcluster -shcluster_label shcluster1

Hva som skjer når du kjører den kommandoen er at Splunk vil oppdatere /opt/splunk/etc/system/local/server.conf Med følgende stanza:

[replication_port:/ /34567]

[shclustering] conf_deploy_fetch_url = https:<shc_master_ip>:<mgmt_port> disabled = 0 mgmt_uri = https:<SH_ip>:<mgmt_port> pass4SymmKey = <secret key> shcluster_label = shcluster1

  - To select the Captain for the Search Heads, run the following command on every search head peer node you want to include in the Cluster:
 
    ```
    ./splunk bootstrap shcluster-captain -servers_list "<URI of search head node>:<management_port>,<URI of search head node>:<management_port>,..." -auth <username>:<password>
    ```
 
    Example format for three search head peers:
 
    ```diff
    + ./splunk bootstrap shcluster-captain -servers_list "https://:8089,https://:8089,https://:8089" -auth admin:password
    ```
 
  - To check the search head cluster status, on search head peers execute the following:
 
    ```
    ./splunk show shcluster-status -auth <username>:<password>
    ```
 
  - To connect the SH cluster with a standalone indexer:
 
    In the search head settings, go to ''Distributed Search'' > ''Add Search Peer'' > Add indexer management port, username, and password.
 
  - To add an Indexer Cluster to the Search Head Cluster, run the following on each search head:
 
    ```
    ./splunk edit cluster-config -mode searchhead -manager_uri https://<Indexer Cluster Master ip>:8089 -auth <username>:<password>
    ```
 
    Example:
 
    ```diff
    + ./splunk edit cluster-config -mode searchhead -manager_uri https://10.128.0.15:8089 -auth admin:splunk1234
    ```
 
  - Cluster Label:
 
    ```
    splunk edit shcluster-config -shcluster_label <CLUSTER LABEL>
    ```
 
  Reference: [[https://docs.splunk.com/Documentation/Splunk/9.0.2/DistSearch/Connectclustersearchheadstosearchpeers|Splunk Documentation]]
  Reference: [[https://docs.splunk.com/Documentation/Splunk/9.0.2/DistSearch/SHCdeploymentoverview|Splunk SHC Deployment Overview]]

<color #ffc90e>SSH to Deployer in the enironment and download the add-on on to the Deployer.
Untar the file and move to /opt/splunk/etc/shcluster/apps, execute the following command.</color>

/opt/splunk/bin/splunk apply shcluster-bundle -target https://<any sh cluster member>:8089 -auth <username>:<password>

<color #ffc90e>

• You will receive a success message after bundle is pushed successfully.
  
• We can verify it by running the following command on any of the search head peers.
  </color>

 /opt/splunk/bin/splunk show shcluster-status