test2 [CQ CQ CQ ..... ]

Denne siden er skrivebeskyttet. Du kan se på den, men ikke endre den. Kontakt administratoren hvis du mener at du bør kunne endre siden.
====== Feilsøking ======
===== Backup måter===== 
**Kopiere med rsync.**\\ 
<code class="bash">
rsync -Hav /opt/splunk/etc /backupmappe/
rsync -Hav -e ssh brukernavn@splunkserver:/opt/splunk/etc /lokalt/mål/
</code>
\\  
**Alternativt å zippe den.**
<code class="bash">
zip -r opt_splunk_etc_hostnavn.zip /opt/splunk/etc  /filbane/med_mye_plass/
</code>
\\ 
<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>
<code class="bash">/opt/splunk/bin/splunk backup kvstore </code>
\\ 
<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.
<code class="bash">
/opt/splunk/bin/splunk diag 
/opt/splunk/bin/splunk diag --target /din/egne/sti/
</code>
Å lage en Diag vil også lage en komplett kopi av etc-mappen uten SSL filer. 
\\ 



===== Søkehode =====
==== KvStore =====
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:
  - <color #ffc90e>Stop Splunk</color>
        - /opt/splunk/bin/splunk stop
  - <color #ffc90e>Tøm kvstore</color>
        - /opt/splunk/bin/splunk clean kvstore –local
  - <color #ffc90e>Start Splunk igjen</color>
        - opt/splunk/bin/splunk start


\\ 
En bedre ryddigere måte er denne:
  - <color #ffc90e>Stop Splunk</color>
        - /opt/splunk/bin/splunk stop
  - <color #ffc90e>Backup the folder</color>
        - /opt/splunk/var/lib/splunk/kvstore/mongo and move the backup somewhere outside Splunk.
  - <color #ffc90e>Invoke</color>
        - /opt/splunk/bin/splunk clean kvstore --cluster
  - <color #ffc90e>Slett mappen og filen</color>
        - /opt/splunk/var/lib/splunk/kvstore/mongo/journal
        - /opt/splunk/var/lib/splunk/kvstore/mongo/mongod.lock
  - <color #ffc90e>Invoke</color>
        - /opt/splunk/bin/mongod --dbpath /opt/splunk/va/r/lib/splunkkvstore/mongo --port=8191 —repair
  - <color #ffc90e>Så kan du starter Splunk igjen</color>
        - /opt/splunk/bin/splunk start 

 
====== Onboarding ======
===== Inputs.conf =====

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

==== Fil monitor =====

<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:
<code class="bash">
    [monitor:///var/log/app.log]
    disabled = false
    index = app_logs
    sourcetype = application_log
</code>
\\ 
==== Datafiltrering ===== 
Eksempelet inkluderer en rekke filtre for å filtrere innsamlede data. Du kan tilpasse disse filtrene etter dine spesifikke behov:
<code class="bash">
[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
</code>
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.

\\ \\ 


==== Redigere CSV ===== 
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>\\  
<code class="bash">
Timestamp,Username,Action,Result
2023-10-13 10:00:00,Alice,Login,Success
2023-10-13 11:15:00,Bob,Update,Failed
</code>
\\ 
<color #ffc90e>Konfigurasjoner i inputs.conf for å dekode CSV-data:</color>\\ 
<code class="bash">
[monitor:///path/to/data.csv]
disabled = false
index = log_data
sourcetype = csv_data
KV_MODE = csv
KV_DELIMITER = ,
NO_BINARY_CHECK = true
</code>
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>\\ 
<code class="bash">
[remove_unwanted_fields]
REGEX = (?:Timestamp|Result),[^,]*,
DEST_KEY = queue
FORMAT = nullQueue

[alias_fields]
FIELDALIAS-action = Action AS EventAction
</code>
\\ 
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.
\\ \\ 
==== Flere filtyper ===== 
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.
<code class="bash">
[monitor:///path/to/logs/*.log,/path/to/logs/*.txt]
disabled = false
index = mixed_logs
sourcetype = mixed_log
</code>
\\ 

==== Lese undermapper ===== 
Her er et eksempel på hvordan du kan bruke /.../ i en filbane i inputs.conf for å overvåke alle undermapper:
<code class="bash">
[monitor:///path/to/logs/.../]
disabled = false
index = log_files
sourcetype = log
</code>
\\ 


==== Filer i rekursive mappe =====
Hvis du vil overvåke spesifikke filtyper i rekursive mapper, for eksempel alle .txt-filer, kan du bruke wildcards som følger:
<code class="bash">
[monitor:///path/to/logs/*.txt]
disabled = false
index = log_files
sourcetype = log
</code>
\\ 

==== Filer i alle undermapper =====
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:

<code class="bash">
[monitor:///path/to/logs/.../.../]
disabled = false
index = log_files
sourcetype = log
</code>
\\ 

==== Filer i alle homes =====
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:
<code class="bash">
[monitor://~/]
disabled = false
index = user_home
sourcetype = user_logs
</code>
\\ 


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

<code class="bash">
[https://bf-esb-internet.edb.com/secesb/rest/era-dsop/v1/4076]
disabled = false
index = api_data
sourcetype = api_event
interval = 300
</code>
\\ 
==== Eksludere innhold =====
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."
<code class="bash">
[monitor:///path/to/your/logfile.log]
disabled = false
index = log_data
sourcetype = your_log
</code>
\\ 

<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.
<code class="bash">
[your_log]
TRANSFORMS-sinkhole = sinkhole
</code>
\\ 

<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.\\ 
<code class="bash">
[sinkhole]
REGEX = .*Sensitive data: (.*)
DEST_KEY = queue
FORMAT = nullQueue
</code>
\\ 

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

<code class="bash">
[tcp://0.0.0.0:514]
disabled = false
index = network_logs
sourcetype = syslog
connection_host = dns
</code>
\\ 


==== Eth monitorering ====
<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:
<code class="bash">
[netmon://my_capture]
disabled = false
index = network_traffic
sourcetype = packet_capture
interface = eth0
</code>
\\ 
==== Maskering av data ====
<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. 
<code class="bash">
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.
</code>
\\ 

<WRAP group>
<WRAP half column>
<color #ffc90e>**inputs.conf**</color>\\ 
<code class="bash">
[monitor:///path/to/sample.log]
disabled = false
index = sample_logs
sourcetype = sample_log
</code>
</WRAP>

<WRAP half column>
<color #ffc90e>**props.conf**</color>\\ 
<code class="bash">
TRANSFORMS-usermask = usermask
</code>
</WRAP>
</WRAP>





<WRAP group>
<WRAP half column>
<color #ffc90e>**transforms.conf**</color>\\ 
<code class="bash">[usermask]
REGEX = (\d{4}-\d{2}-\d{2} \d{2}:\d{2}):\sUser (\w+)
FORMAT = $1: User xxx
</code>
</WRAP>

<WRAP half column>
<color #ffc90e>**Slik vil loggen bli seende ut når den blir lest av Splunk**</color>\\ 
<code class="bash">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.
</code>
</WRAP>
</WRAP>
\\ \\ 



==== Kombinere filer ====
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.\\ \\ 

<WRAP group>
<WRAP half column>
<color #ffc90e>Logg 1 - Eksempellogg fra Windows påloggingslogg (log1.log)</color>\\  
<code class="bash">
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.
</code>
</WRAP>

<WRAP half column>
<color #ffc90e>Logg 2 - Eksempellogg fra Netflow-loggen (log2.log)</color>\\ 
<code class="bash">
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.
</code>
</WRAP>
</WRAP>
\\ 

<color #ffc90e>inputs.conf for å overvåke begge loggene</color>\\ 
Her overvåker vi begge loggene og angir forskjellige sourcetypes for hver.
<code class="bash">
[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
</code>
\\ 

<color #ffc90e>props.conf for å kombinere dataene</color>\\ 
<code class="bash">
[windows_log]
REPORT-windows_user = extract_windows_user

[netflow_log]
REPORT-windows_user = extract_windows_user

[log_data]
TRANSFORMS-add_username = combine_logs
</code>
\\ 

<color #ffc90e>transforms.conf for å kombinere dataene</color>\\ 
<code class="bash">
[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
</code>
\\ 

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.
\\ \\ 
===== Heavy Forwarder =====
<WRAP group>
<WRAP half column>
<color #ffc90e>Data Transformasjon</color>\\ 
En Heavy Forwarder kan utføre data-transformasjoner ved hjelp av SEDCMD i props.conf og andre konfigurasjoner. Du kan reformatere, filtrere, maskere, eller berike dataene før de sendes videre til indeksering.

<color #ffc90e>Data Aggregasjon</color>\\ 
En Heavy Forwarder kan aggregere data fra flere kilder før de sendes til indeksering. Dette er nyttig når du ønsker å kombinere og summere data fra flere kilder før de blir analysert.

<color #ffc90e>Parsing og Tokenization</color>\\ 
Du kan bruke Heavy Forwarder til å parse komplekse datastrukturer som JSON eller XML og deretter sende individuelle felt til indeksering. Dette gir deg mer granulær søkbarhet i dine data.

<color #ffc90e>Data Reduction</color>\\ 
Heavy Forwarder kan redusere datavolum ved å filtrere ut unødvendige eller like data før indeksering. Dette er spesielt nyttig for å redusere kostnadene knyttet til datalagring.

<color #ffc90e>Load Balancing</color>\\ 
En Heavy Forwarder kan implementere lastbalansering for å fordele datainnsamlingen jevnt over flere indeksklyngemedlemmer. Dette forbedrer ytelsen og påliteligheten i en distribuert Splunk-miljø.

<color #ffc90e>Forwarding til flere mål</color>\\ 
Du kan konfigurere Heavy Forwarder til å sende data til flere mottakere, for eksempel flere indekser eller en SIEM-løsning samtidig.
</WRAP>

<WRAP half column>
<color #ffc90e>Regex-filtrering</color>\\ 
En Heavy Forwarder kan bruke mer avanserte regulære uttrykk (regex) for filtrering og transformasjon av dataene, noe som gir mer fleksibilitet i datahåndteringen.

<color #ffc90e>Kapasitetsplanlegging</color>\\ 
Du kan optimalisere ressursbruk og ytelse på Heavy Forwarder for å håndtere høy datavolum.

<color #ffc90e>Sikkerhet og Kryptering</color>\\ 
Heavy Forwarder gir flere alternativer for å sikre dataoverføringer, inkludert SSL/TLS-kryptering og godkjenning.

<color #ffc90e>Meldingsvarslinger</color>\\ 
En Heavy Forwarder kan overvåke hendelser og utføre handlinger som å sende varsler eller utføre skriptbaserte oppgaver basert på hendelseskriterier.

<color #ffc90e>Konvertering til Splunk Enterprise Security CIM-format</color>\\ 
Hvis du bruker Splunk Enterprise Security, kan en Heavy Forwarder konvertere hendelsesdata til Splunk Common Information Model (CIM)-format for å støtte sikkerhetsovervåking og trusselintelligens.

<color #ffc90e>Komplekse datakilder</color>\\ 
Heavy Forwarder kan håndtere komplekse datakilder som Windows-lesebånd, SQL-databaser, og andre datakilder som krever spesiell behandling.
</WRAP>
</WRAP>



==== Tilpasse CIM data ====
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>\\  
<code class="bash">
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
</code>
\\ 
<WRAP group>
<WRAP half column>
<color #ffc90e>Konfigurasjoner i inputs.conf for å overvåke loggdatafilen</color>\\  
<code class="bash">
[monitor:///path/to/loggdata.txt]
disabled = false
index = cim_index
sourcetype = cim_data
</code>
</WRAP>

<WRAP half column>
<color #ffc90e>Konfigurasjoner i props.conf for konvertering til CIM-format:</color>\\ 
<code class="bash">
SHOULD_LINEMERGE = false
TRANSFORMS-cim = set_cim_fields
</code>
</WRAP>
</WRAP>



\\ 

<color #ffc90e>Konfigurasjoner i transforms.conf for CIM-formatkonvertering:</color>\\  
<code class="bash">
[set_cim_fields]
REGEX = (?m)^(?<timestamp>\S+) (?<event_id>\d+) (?<event_type>\S+).*?
FORMAT = cim::$1::$2::$3
</code>
\\ 
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.

\\ 
\\ 



==== Tag eventer med HF felt ====
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>
<code class="bash">
[_]
TRANSFORMS-sethf = set_heavyforwarder_field
</code> 
<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:

<code class="bash">
[set_heavyforwarder_field]
REGEX = .
DEST_KEY = _MetaData:HF_Name
FORMAT = HeavyForwarderName
</code> \\ 

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.

\\ \\ 
==== Maskere med SEDcmd ====
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>\\ 
<code class="bash">
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
</code>
\\ 
<color #ffc90e>Konfigurasjoner i props.conf for data-transformasjon</color>\\ 
<code class="bash">
[data_transform]
SEDCMD-password = s/Passord: [^,]*/Passord: maskert/
</code>
\\ 
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>\\ 
<code class="bash">
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
</code>
\\ \\ 
==== Hashe og unhashe ====
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.


<WRAP group>
<WRAP half column>
<color #ffc90e>Sikkerhet</color>\\  Hvis du har muligheten til å reversere passord, må du sørge for at dehashingsprosessen er svært sikker og beskyttet. Passord er sensitive data, og du må forhindre at de blir kompromittert.

<color #ffc90e>Datakontroll</color>\\ Du må opprettholde streng kontroll over dehashingsalgoritmen og eventuelle nøkler eller data som er nødvendige for prosessen. Dette inkluderer beskyttelse mot uautorisert tilgang..
</WRAP>

<WRAP half column>
<color #ffc90e>Lovlige krav</color>\\ Sørg for å overholde relevante personvernlover og regelverk når du håndterer passord og personlige data.

<color #ffc90e>Alternativer</color>\\ Vurder om det er alternative metoder for å gjenopprette passord, for eksempel tilbakestilling av passord ved bruk av e-postbekreftelse, tofaktorautentisering eller lignende.

</WRAP>
</WRAP>
=== Eksempel ===
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>
<code class="bash">
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
</code>
\\ 

<color #ffc90e>Konfigurasjoner i props.conf for maskering og dekryptering</color>
<code class="bash">
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/
</code>
\\ 
<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.
<code class="bash">
sourcetype=masked_data | eval MaskedCC = coalesce(mvindex(replace("Kredittkort: xxx"),0,"Kredittkort: ")) | table _time, Bruker, MaskedCC
</code>
\\ 


<color #ffc90e>Søk for å dekryptere kredittkortnumre</color>
<code class="bash">
sourcetype=masked_data | eval DecryptedCC = coalesce(mvindex(replace("Kredittkort: 1234-5678-9012-3456"),0,"Kredittkort: ")) | table _time, Bruker, DecryptedCC
</code>
\\ 
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.
\\ \\ 


==== Load Balancing ====
<color #ffc90e>Stanza for load balansing</color>\\ 
Dette vil sende data til en gruppe som heter load_balancer som inneholder 3 servere.
<code class="bash">
[tcpout]
defaultGroup = load_balancer

[tcpout:load_balancer]
server = canada_indexer1:9997, london_indexer1:9997, oslo_indexer1:9997
</code>
\\ 

==== Sende kopier ====
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>
<code class="bash">
[tcpout]
defaultGroup = my_indexers

[tcpout:my_indexers]
server = indexer1:9997, indexer2:9997

[tcpout:siem]
server = siem_server:514
</code>
\\ 

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


==== Alerts fra HF ====
Eksempel på Loggdata:

<color #ffc90e>La oss anta at du har følgende loggdata i en fil som inneholder sikkerhetshendelser</color>
<code class="bash">
[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
</code> \\ 
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>
<code class="bash">
[my_security_alert]
condition = (sourcetype="security_logs") AND (severity="high")
action.email = security-team@example.com
</code> \\ 



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>
<code class="bash">
[monitor:///path/to/security.log]
sourcetype = security_logs
props.conf-konfigurasjon:
</code> \\ 

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>
<code class="bash">
[security_logs]
TRANSFORMS-set_sourcetype = set_sourcetype
</code> \\ 


I transforms.conf kan du definere en transformasjon for å tilordne riktig sourcetype.\\ 
<color #ffc90e>transforms.conf-konfigurasjon</color>
<code class="bash">
[set_sourcetype]
REGEX = sourcetype = (.+)
DEST_KEY = MetaData:Sourcetype
FORMAT = sourcetype::$1
</code> \\ 
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.



===== Ytelse Søking =====
==== Ytelsemåling ====

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>
<code class="bash">
index=_internal source="*metrics.log" host=(hf1 OR hf2 OR hf3) metric_name="queueSize" 
| timechart span=1h max(current) as "Forwarder Queue" by host
</code> \\ 

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>
<code class="bash">
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
</code> \\ 
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>
<code class="bash">
index=_internal source="*metrics.log" metric_name="queueSize" queue="parsingQueue" 
| stats max(current) as "Parsing Queue" by host
</code> \\ 
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>
<code class="bash">
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
</code> \\ 



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



==== Ytelsemåling 2 ====
<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>
<code class="bash">
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
</code> \\

<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.
<code class="bash">
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
</code> \\ 

<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
<code class="bash">index=_internal source="*metrics.log" metric_name="queueSize" queue="search_queue" host=sh1</code>
\\ 
\\ 
<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
<code class="bash">
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
</code> \\ \\ 

====== Cluster konfigurasjon ======

===== Søkehode Cluster =====


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.

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


==== På hvert søkehode ====


 - 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
<code class="bash"> 
./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
</code>
\\ 
Søkehode 2
<code class="bash">
    ./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
</code>
\\ 
Søkehode 3
<code class="bash">./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
</code>
\\ 


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




<code class="bash">
  - 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]]
</code>









===== Sende ut app til SH Cluster =====

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


<code class="bash">
/opt/splunk/bin/splunk apply shcluster-bundle -target https://<any sh cluster member>:8089 -auth <username>:<password>
</code>
{{:splunkgruppe:apply-shclusterbundle.png?nolink&800|}}


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

<code class="bash"> /opt/splunk/bin/splunk show shcluster-status</code>

{{:splunkgruppe:apply-shclusterbundle2.png?nolink&800|}}
Brukerverktøy

Nettstedverktøy

Sideverktøy
