====== Feilsøking ====== ===== Backup måter===== **Kopiere med rsync.**\\ rsync -Hav /opt/splunk/etc /backupmappe/ rsync -Hav -e ssh brukernavn@splunkserver:/opt/splunk/etc /lokalt/mål/ \\ **Alternativt å zippe den.** zip -r opt_splunk_etc_hostnavn.zip /opt/splunk/etc /filbane/med_mye_plass/ \\ Kvstore backup\\ KvStore krever en egen backup løsning som Splunk må gjøre.Og den blir lagret i /opt/splunk/var/lib/splunk/kvstorebackup. /opt/splunk/bin/splunk backup kvstore \\ Splunk diag fil\\ Normalt vil den bli lagret i /opt/splunk/etc/var/run/splunk/splunk_diag_logs/\\ 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. \\ ===== 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: - Stop Splunk - /opt/splunk/bin/splunk stop - Tøm kvstore - /opt/splunk/bin/splunk clean kvstore –local - Start Splunk igjen - opt/splunk/bin/splunk start \\ En bedre ryddigere måte er denne: - Stop Splunk - /opt/splunk/bin/splunk stop - Backup the folder - /opt/splunk/var/lib/splunk/kvstore/mongo and move the backup somewhere outside Splunk. - Invoke - /opt/splunk/bin/splunk clean kvstore --cluster - Slett mappen og filen - /opt/splunk/var/lib/splunk/kvstore/mongo/journal - /opt/splunk/var/lib/splunk/kvstore/mongo/mongod.lock - Invoke - /opt/splunk/bin/mongod --dbpath /opt/splunk/va/r/lib/splunkkvstore/mongo --port=8191 —repair - Så kan du starter Splunk igjen - /opt/splunk/bin/splunk start ====== Onboarding ====== ===== Inputs.conf ===== Inputs.conf-filen 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. \\ \\ **Kildevurdering:**\\ 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 ===== **Loggfiler:**\\ 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 \\ ==== Datafiltrering ===== 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 = crcSalt = _ [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: host\\ Angir vertens navn (vertshost) for hendelsene. Dette kan brukes til å filtrere hendelser fra en bestemt kilde. blacklist\\ Filtret ekskluderer hendelser som samsvarer med det gitte regex-mønsteret. I dette tilfellet ekskluderer det bildefiler (jpg, png, gif) fra innsamlingen. whitelist\\ 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. crcSalt\\ Angir en "salt" for CRC-beregning. Dette er nyttig for å unngå konflikter og endringer i CRC-verdien hvis kilden eller verten endres. maxDaysAgo\\ 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:\\ Eksempellogg i CSV-format (data.csv)\\ Timestamp,Username,Action,Result 2023-10-13 10:00:00,Alice,Login,Success 2023-10-13 11:15:00,Bob,Update,Failed \\ Konfigurasjoner i inputs.conf for å dekode CSV-data:\\ [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.\\ \\ Konfigurasjoner i transforms.conf for å fjerne unødvendige felt:\\ [remove_unwanted_fields] REGEX = (?:Timestamp|Result),[^,]*, DEST_KEY = queue FORMAT = nullQueue [alias_fields] FIELDALIAS-action = Action AS EventAction \\ Her bruker vi transforms.conf til å konfigurere to transformasjoner: remove_unwanted_fields fjerner feltene "Timestamp" og "Result" ved å sende dem til nullQueue. Dette filtrerer ut unødvendige felt. alias_fields oppretter en alias for feltet "Action" ved å omdøpe det til "EventAction." 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. [monitor:///path/to/logs/*.log,/path/to/logs/*.txt] disabled = false index = mixed_logs sourcetype = mixed_log \\ ==== Lese undermapper ===== 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 \\ ==== 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: [monitor:///path/to/logs/*.txt] disabled = false index = log_files sourcetype = log \\ ==== 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: [monitor:///path/to/logs/.../.../] disabled = false index = log_files sourcetype = log \\ ==== 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: [monitor://~/] disabled = false index = user_home sourcetype = user_logs \\ ==== Lese API data ===== 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 \\ ==== 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: **inputs.conf**\\ 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 \\ **props.conf**\\ 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 \\ **transforms.conf**\\ 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 \\ ==== 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. [tcp://0.0.0.0:514] disabled = false index = network_logs sourcetype = syslog connection_host = dns \\ ==== Eth monitorering ==== **Nettverkssniffer:**\\ 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 \\ ==== Maskering av data ==== **Logg eksempel:**\\ 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. \\ **inputs.conf**\\ [monitor:///path/to/sample.log] disabled = false index = sample_logs sourcetype = sample_log **props.conf**\\ TRANSFORMS-usermask = usermask **transforms.conf**\\ [usermask] REGEX = (\d{4}-\d{2}-\d{2} \d{2}:\d{2}):\sUser (\w+) FORMAT = $1: User xxx **Slik vil loggen bli seende ut når den blir lest av Splunk**\\ 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. \\ \\ ==== 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.\\ \\ Logg 1 - Eksempellogg fra Windows påloggingslogg (log1.log)\\ 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. Logg 2 - Eksempellogg fra Netflow-loggen (log2.log)\\ 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. \\ inputs.conf for å overvåke begge loggene\\ 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 \\ props.conf for å kombinere dataene\\ [windows_log] REPORT-windows_user = extract_windows_user [netflow_log] REPORT-windows_user = extract_windows_user [log_data] TRANSFORMS-add_username = combine_logs \\ transforms.conf for å kombinere dataene\\ [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 extract_windows_user brukes for å hente brukernavn og IP fra Windows påloggingsloggen. Den andre transformasjonen combine_logs 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 ===== Data Transformasjon\\ 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. Data Aggregasjon\\ 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. Parsing og Tokenization\\ 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. Data Reduction\\ 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. Load Balancing\\ En Heavy Forwarder kan implementere lastbalansering for å fordele datainnsamlingen jevnt over flere indeksklyngemedlemmer. Dette forbedrer ytelsen og påliteligheten i en distribuert Splunk-miljø. Forwarding til flere mål\\ Du kan konfigurere Heavy Forwarder til å sende data til flere mottakere, for eksempel flere indekser eller en SIEM-løsning samtidig. Regex-filtrering\\ 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. Kapasitetsplanlegging\\ Du kan optimalisere ressursbruk og ytelse på Heavy Forwarder for å håndtere høy datavolum. Sikkerhet og Kryptering\\ Heavy Forwarder gir flere alternativer for å sikre dataoverføringer, inkludert SSL/TLS-kryptering og godkjenning. Meldingsvarslinger\\ En Heavy Forwarder kan overvåke hendelser og utføre handlinger som å sende varsler eller utføre skriptbaserte oppgaver basert på hendelseskriterier. Konvertering til Splunk Enterprise Security CIM-format\\ 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. Komplekse datakilder\\ Heavy Forwarder kan håndtere komplekse datakilder som Windows-lesebånd, SQL-databaser, og andre datakilder som krever spesiell behandling. ==== 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 Loggdatafil (loggdata.txt)\\ 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 \\ Konfigurasjoner i inputs.conf for å overvåke loggdatafilen\\ [monitor:///path/to/loggdata.txt] disabled = false index = cim_index sourcetype = cim_data Konfigurasjoner i props.conf for konvertering til CIM-format:\\ SHOULD_LINEMERGE = false TRANSFORMS-cim = set_cim_fields \\ Konfigurasjoner i transforms.conf for CIM-formatkonvertering:\\ [set_cim_fields] REGEX = (?m)^(?\S+) (?\d+) (?\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. \\ \\ ==== 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.\\ Add the following stanza to props.conf [_] TRANSFORMS-sethf = set_heavyforwarder_field In the above configuration:\\ [_] is the default stanza that applies to all events.\\ set_heavyforwarder_field\\ 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: set_heavyforwarder_field 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. Loggdatafil (loggdata.txt)\\ 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 \\ Konfigurasjoner i props.conf for data-transformasjon\\ [data_transform] SEDCMD-password = s/Passord: [^,]*/Passord: maskert/ \\ I props.conf 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. \\ Loggdata etter data-transformasjon\\ 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 \\ \\ ==== Hashe og unhashe ==== Såkaldt "dehashing" eller "unhashing", 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.svar med gjeldende lover og beste praksis. Sikkerhet\\ 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. Datakontroll\\ 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.. Lovlige krav\\ Sørg for å overholde relevante personvernlover og regelverk når du håndterer passord og personlige data. Alternativer\\ Vurder om det er alternative metoder for å gjenopprette passord, for eksempel tilbakestilling av passord ved bruk av e-postbekreftelse, tofaktorautentisering eller lignende. === 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.\\ Loggdatafil (loggdata.txt) 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 \\ Konfigurasjoner i props.conf for maskering og dekryptering 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/ \\ I props.conf har vi definert to konfigurasjoner\\ 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.\\ \\ Søk for å maskere kredittkortnumre\\ 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 \\ Søk for å dekryptere kredittkortnumre 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 krypterte og dekrypterte 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 ==== Stanza for load balansing\\ 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 \\ ==== 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. Konfigurasjon i outputs.conf på Heavy Forwarder [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. \\ \\ ==== Alerts fra HF ==== Eksempel på Loggdata: La oss anta at du har følgende loggdata i en fil som inneholder sikkerhetshendelser [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)\\ alerts.conf-konfigurasjon [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.\\ inputs.conf-konfigurasjon [monitor:///path/to/security.log] sourcetype = security_logs props.conf-konfigurasjon: \\ Her er en enkel eksempelkonfigurasjon for å angi sourcetype og transformere logghendelsene.\\ Hvis du ønsker å endre eller formatere dataene før indeksering, kan du bruke props.conf [security_logs] TRANSFORMS-set_sourcetype = set_sourcetype \\ I transforms.conf kan du definere en transformasjon for å tilordne riktig sourcetype.\\ transforms.conf-konfigurasjon [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. ===== 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.\\ Søk for å vise Forwarder køen på Heavy Forwarders over 4 timer 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.\\ Søk for å vise søkerkøen, forberedelseskøen og distribusjonskøen på Søkehodeklyngen over 4 timer 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).\\ Søk for å vise Parsing Queue og dens kilde 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.\\ Søk for å vise HEC køen på alle indexerne over 4 timer 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- ==== Ytelsemåling 2 ==== Søkehodekøer\\ 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. \\ Søk for å vise Forwarder køen på Heavy Forwarders over 4 timer 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 \\ Cluster-spesifikke køer\\ 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 \\ Logg og varsling\\ 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. Gå til Splunk Web, og velg "Settings" -> "Alerts." Klikk på "New Alert" for å opprette en ny varsling.\\ Angi en terskel for køstørrelsen, for eksempel "greater than 1000." 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 \\ \\ Heavy Forwarder-køer\\ 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 \\ \\ ====== 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. - In the Deployer, edit ''/opt/splunk/etc/system/local/server.conf'' as follows: ``` [shclustering] pass4SymmKey = password shcluster_label = shcluster1 ``` ==== På hvert søkehode ==== - In the Search Head Peer Node, execute the following command: ./splunk init shcluster-config -auth : -mgmt_uri : -replication_port -replication_factor -conf_deploy_fetch_url : -secret -shcluster_label