test2
Forskjeller
Her vises forskjeller mellom den valgte versjonen og den nåværende versjonen av dokumentet.
| Begge sider forrige revisjonForrige revisjonNeste revisjon | Forrige revisjon | ||
| test2 [2023/10/16 03:36] – admin99 | test2 [2024/03/05 01:16] (nåværende versjon) – admin99 | ||
|---|---|---|---|
| Linje 1: | Linje 1: | ||
| - | test I wanted to revert to the narrower page width of the default dokuwiki template. I tried several suggested methods, including editing the style.ini value __site_width__ without success. The best I could do was edit the main.php (in the template) with the following: | ||
| - | | + | ====== Feilsøking ====== |
| - | –Coreigh 11/18/2014 | + | ===== Backup måter===== |
| + | **Kopiere med rsync.**\\ | ||
| + | <code class=" | ||
| + | rsync -Hav / | ||
| + | rsync -Hav -e ssh brukernavn@splunkserver:/ | ||
| + | </ | ||
| + | \\ | ||
| + | **Alternativt å zippe den.** | ||
| + | <code class="bash"> | ||
| + | zip -r opt_splunk_etc_hostnavn.zip / | ||
| + | </ | ||
| + | \\ | ||
| + | <color # | ||
| + | KvStore krever en egen backup løsning som Splunk må gjøre.Og den blir lagret i <color # | ||
| + | <code class=" | ||
| + | \\ | ||
| + | <color # | ||
| + | Normalt vil den bli lagret i <color #ffc90e>/opt/ | ||
| + | Eksemplet viser også hvordan du kan overstyre filstien. | ||
| + | <code class=" | ||
| + | / | ||
| + | / | ||
| + | </ | ||
| + | Å lage en Diag vil også lage en komplett kopi av etc-mappen uten SSL filer. | ||
| + | \\ | ||
| - | From version 0.8.5 the content stops getting wider at 1152px | ||
| - | —Klaus 04/10/2015 | ||
| - | IMO: best template 8-) . One improvement idea: set different background images for namespaces/ | ||
| - | —PDriverX 03/04/2015 | + | ===== 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 # | ||
| + | - /opt/ | ||
| + | - <color # | ||
| + | - / | ||
| + | - <color # | ||
| + | - opt/ | ||
| - | will have to look into that. It definitely possible, but I don't know how difficult it will be. It will surely not be possible to set the background image within the page content but a background image with the same basename as the page may be imaginable. | ||
| - | —Klaus 04/10/2015 | ||
| - | Hi, on updating the template to version 2015-04-28, the transparency changed. Now the background image is mostly invisible because of brighter foreground. Is there a chance to change this (and where)? The white font on top “Sie befinden sich hier::” is also invisible because of similar colors… | + | \\ |
| - | —PDriverX 05/22/2015 | + | En bedre ryddigere måte er denne: |
| + | | ||
| + | | ||
| + | - <color # | ||
| + | - / | ||
| + | - <color # | ||
| + | - / | ||
| + | - <color # | ||
| + | - / | ||
| + | - / | ||
| + | - <color # | ||
| + | - / | ||
| + | - <color # | ||
| + | - /opt/splunk/bin/splunk start | ||
| - | Whopss… fixed the problem by uninstalling wallpaper template and reinstalling it. So, if you have the same problems with transparency, | + | |
| - | —PDriverX 05/22/2015 | + | ====== Onboarding ====== |
| + | ===== Inputs.conf ===== | ||
| - | Hi, great template! | + | <color # |
| - | - How do I get the menu to show in the top bar? I have tried both auto generated and a “menu” | + | Den har mange muligheter, og jeg vil forsøke å liste noen gode eksempler. \\ |
| - | I have ignored | + | \\ |
| - | - How do I get at the configuration items when I run the template this way, they are not there. | + | <color # |
| - | - How do I get the page to take up full width, like I can with the main dokuwiki template. (i.e I used the following in my main style.ini) | + | Du kan også bruke " |
| + | som ekstrahering og transformasjon av data før indeksering.\\ | ||
| + | Husk at konfigurasjonen avhenger av datakildene og kravene dine. Du bør tilpasse " | ||
| + | |||
| + | ==== Fil monitor ===== | ||
| + | |||
| + | <color # | ||
| + | Du kan konfigurere Splunk til å overvåke loggfiler og indeksere data fra dem. \\ | ||
| + | Dette vil overvåke filen "/ | ||
| + | spesiell sourcetype " | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | 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: | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = log_data | ||
| + | sourcetype = custom_log | ||
| + | host = webserver | ||
| + | blacklist = \.(jpg|png|gif)$ | ||
| + | whitelist = ^/pages/ | ||
| + | crcSalt = < | ||
| + | crcSalt = < | ||
| + | |||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = log_data | ||
| + | sourcetype = custom_log | ||
| + | host = appserver | ||
| + | whitelist = ^/api/ | ||
| + | whitelist = ^/admin/ | ||
| + | maxDaysAgo = 7 | ||
| + | </ | ||
| + | I dette eksempelet har vi konfigurert | ||
| + | |||
| + | <color # | ||
| + | Angir vertens navn (vertshost) for hendelsene. Dette kan brukes til å filtrere hendelser fra en bestemt kilde. | ||
| + | |||
| + | <color # | ||
| + | Filtret ekskluderer hendelser som samsvarer med det gitte regex-mønsteret. | ||
| + | |||
| + | <color # | ||
| + | Filtret inkluderer bare hendelser som samsvarer med det gitte regex-mønsteret. I dette tilfellet inkluderer det bare hendelser som starter med "/ | ||
| + | |||
| + | <color # | ||
| + | Angir en " | ||
| + | |||
| + | <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, | ||
| + | |||
| + | \\ \\ | ||
| + | |||
| + | |||
| + | ==== Redigere CSV ===== | ||
| + | Her er et eksempel på hvordan du kan bruke KV_MODE, KV_DELIMITER, | ||
| + | <color # | ||
| + | <code class=" | ||
| + | Timestamp, | ||
| + | 2023-10-13 10: | ||
| + | 2023-10-13 11: | ||
| + | </ | ||
| + | \\ | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | 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 # | ||
| + | <code class=" | ||
| + | [remove_unwanted_fields] | ||
| + | REGEX = (?: | ||
| + | DEST_KEY = queue | ||
| + | FORMAT = nullQueue | ||
| + | |||
| + | [alias_fields] | ||
| + | FIELDALIAS-action = Action AS EventAction | ||
| + | </ | ||
| + | \\ | ||
| + | Her bruker vi <color # | ||
| + | |||
| + | remove_unwanted_fields fjerner feltene <color # | ||
| + | |||
| + | alias_fields oppretter en alias for feltet <color # | ||
| + | |||
| + | 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=" | ||
| + | [monitor:/// | ||
| + | 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: | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | 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: | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | 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, | ||
| + | |||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | 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: | ||
| + | <code class=" | ||
| + | [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. | ||
| + | |||
| + | <code class=" | ||
| + | [https:// | ||
| + | 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: | ||
| + | |||
| + | <color # | ||
| + | Dette vil overvåke loggfilen " | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = log_data | ||
| + | sourcetype = your_log | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | Her har vi definert et transformasjonsnavn " | ||
| + | <code class=" | ||
| + | [your_log] | ||
| + | TRANSFORMS-sinkhole = sinkhole | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | I dette eksempelet bruker vi en REGEX for å identifisere linjer som inneholder " | ||
| + | Når du har satt opp disse konfigurasjonene, | ||
| + | \\ | ||
| + | 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=" | ||
| + | [sinkhole] | ||
| + | REGEX = .*Sensitive data: (.*) | ||
| + | DEST_KEY = queue | ||
| + | FORMAT = nullQueue | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | ==== TCP og UDP data ==== | ||
| + | Splunk kan lytte på nettverksporter for å fange inn datastrømmer, | ||
| + | |||
| + | <code class=" | ||
| + | [tcp:// | ||
| + | disabled = false | ||
| + | index = network_logs | ||
| + | sourcetype = syslog | ||
| + | connection_host = dns | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | |||
| + | ==== Eth monitorering ==== | ||
| + | <color # | ||
| + | Dette vil fange nettverkstrafikken fra grensesnittet " | ||
| + | Hvis du vil fange nettverkstrafikk, | ||
| + | <code class=" | ||
| + | [netmon:// | ||
| + | disabled = false | ||
| + | index = network_traffic | ||
| + | sourcetype = packet_capture | ||
| + | interface = eth0 | ||
| + | </ | ||
| + | \\ | ||
| + | ==== Maskering av data ==== | ||
| + | <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=" | ||
| + | 2023-10-13 10:30: User Alice logged in. | ||
| + | 2023-10-13 11:45: User Bob updated | ||
| + | 2023-10-13 12:15: User Carol logged in. | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = sample_logs | ||
| + | sourcetype = sample_log | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | TRANSFORMS-usermask = usermask | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | REGEX = (\d{4}-\d{2}-\d{2} \d{2}: | ||
| + | FORMAT = $1: User xxx | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | 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, | ||
| + | |||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | 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. | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | 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 # | ||
| + | Her overvåker vi begge loggene og angir forskjellige sourcetypes for hver. | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = log_data | ||
| + | sourcetype = windows_log | ||
| + | |||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = log_data | ||
| + | sourcetype = netflow_log | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | [windows_log] | ||
| + | REPORT-windows_user = extract_windows_user | ||
| + | |||
| + | [netflow_log] | ||
| + | REPORT-windows_user = extract_windows_user | ||
| + | |||
| + | [log_data] | ||
| + | TRANSFORMS-add_username = combine_logs | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | [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 # | ||
| + | |||
| + | Den andre transformasjonen <color # | ||
| + | |||
| + | Når du har konfigurert disse filene, vil Splunk kombinere dataene fra de to kildene basert på IP-adressen, | ||
| + | \\ \\ | ||
| + | ===== Heavy Forwarder ===== | ||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | En Heavy Forwarder kan utføre data-transformasjoner ved hjelp av SEDCMD i props.conf og andre konfigurasjoner. Du kan reformatere, | ||
| + | |||
| + | <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 # | ||
| + | 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 # | ||
| + | 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 # | ||
| + | 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 # | ||
| + | Du kan konfigurere Heavy Forwarder til å sende data til flere mottakere, for eksempel flere indekser eller en SIEM-løsning samtidig. | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <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 # | ||
| + | Du kan optimalisere ressursbruk og ytelse på Heavy Forwarder for å håndtere høy datavolum. | ||
| + | |||
| + | <color # | ||
| + | Heavy Forwarder gir flere alternativer for å sikre dataoverføringer, | ||
| + | |||
| + | <color # | ||
| + | En Heavy Forwarder kan overvåke hendelser og utføre handlinger som å sende varsler eller utføre skriptbaserte oppgaver basert på hendelseskriterier. | ||
| + | |||
| + | <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 # | ||
| + | Heavy Forwarder kan håndtere komplekse datakilder som Windows-lesebånd, | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | ==== Tilpasse CIM data ==== | ||
| + | Her er et komplett eksempel med en loggdatafil, | ||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | 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 | ||
| + | </ | ||
| + | \\ | ||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | disabled = false | ||
| + | index = cim_index | ||
| + | sourcetype = cim_data | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | <code class=" | ||
| + | SHOULD_LINEMERGE = false | ||
| + | TRANSFORMS-cim = set_cim_fields | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | [set_cim_fields] | ||
| + | REGEX = (? | ||
| + | FORMAT = cim:: | ||
| + | </ | ||
| + | \\ | ||
| + | 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 " | ||
| + | |||
| + | 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 | ||
| + | |||
| + | Here's how you can achieve this: | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | Edit the props.conf | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [_] | ||
| + | TRANSFORMS-sethf = set_heavyforwarder_field | ||
| + | </ | ||
| + | <color # | ||
| + | [_] is the default stanza that applies to all events.\\ | ||
| + | |||
| + | |||
| + | <color # | ||
| + | Is the name of the transform that we'll define in the next step.\\ | ||
| + | Create a transforms.conf | ||
| + | |||
| + | <code class=" | ||
| + | [set_heavyforwarder_field] | ||
| + | REGEX = . | ||
| + | DEST_KEY = _MetaData: | ||
| + | FORMAT = HeavyForwarderName | ||
| + | </ | ||
| + | |||
| + | In this configuration: | ||
| + | |||
| + | <color # | ||
| + | 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 | ||
| + | With this configuration, | ||
| + | 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 # | ||
| + | <code class=" | ||
| + | 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 # | ||
| + | <code class=" | ||
| + | [data_transform] | ||
| + | SEDCMD-password = s/Passord: [^, | ||
| + | </ | ||
| + | \\ | ||
| + | I <color # | ||
| + | |||
| + | 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 # | ||
| + | <code class=" | ||
| + | 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 <color # | ||
| + | Hvis du har spesielle krav for passordhåndtering, | ||
| + | |||
| + | |||
| + | <WRAP group> | ||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | |||
| + | <color # | ||
| + | </ | ||
| + | |||
| + | <WRAP half column> | ||
| + | <color # | ||
| + | |||
| + | <color # | ||
| + | |||
| + | </ | ||
| + | </ | ||
| + | === 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 # | ||
| + | <code class=" | ||
| + | 2023-10-13 14:25:10 - Bruker: alice, Kredittkort: | ||
| + | 2023-10-13 14:30:15 - Bruker: bob, Kredittkort: | ||
| + | 2023-10-13 14:35:20 - Bruker: carol, Kredittkort: | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | SEDCMD-mask_credit_card = s/ | ||
| + | SEDCMD-decrypt_credit_card = s/ | ||
| + | </ | ||
| + | \\ | ||
| + | <color #ffc90e>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.\\ \\ | ||
| + | |||
| + | |||
| + | <color # | ||
| + | Nå kan vi søke etter dataene og bruke maskering og dekryptering i Splunk. Her er noen eksempler på søk. | ||
| + | <code class=" | ||
| + | sourcetype=masked_data | eval MaskedCC = coalesce(mvindex(replace(" | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | |||
| + | <color # | ||
| + | <code class=" | ||
| + | sourcetype=masked_data | eval DecryptedCC = coalesce(mvindex(replace(" | ||
| + | </ | ||
| + | \\ | ||
| + | Disse søkene vil vise loggdataene med maskerte <color # | ||
| + | |||
| + | Merk at dette eksempelet er en enkel illustrasjon av maskering og dekryptering i Splunk. | ||
| + | \\ \\ | ||
| + | |||
| + | |||
| + | ==== Load Balancing ==== | ||
| + | <color # | ||
| + | Dette vil sende data til en gruppe som heter load_balancer som inneholder 3 servere. | ||
| + | <code class=" | ||
| + | [tcpout] | ||
| + | defaultGroup = load_balancer | ||
| + | |||
| + | [tcpout: | ||
| + | server = canada_indexer1: | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | ==== 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 # | ||
| + | <code class=" | ||
| + | [tcpout] | ||
| + | defaultGroup = my_indexers | ||
| + | |||
| + | [tcpout: | ||
| + | server = indexer1: | ||
| + | |||
| + | [tcpout: | ||
| + | server = siem_server: | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | I dette eksempelet har vi definert | ||
| + | |||
| + | 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 # | ||
| + | <code class=" | ||
| + | [2023-10-13 10:00:00] Source IP: 192.168.1.100, | ||
| + | [2023-10-13 10:15:00] Source IP: 192.168.1.101, | ||
| + | [2023-10-13 10:30:00] Source IP: 192.168.1.102, | ||
| + | </ | ||
| + | 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 | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [my_security_alert] | ||
| + | condition = (sourcetype=" | ||
| + | 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 # | ||
| + | <code class=" | ||
| + | [monitor:/// | ||
| + | sourcetype = security_logs | ||
| + | props.conf-konfigurasjon: | ||
| + | </ | ||
| + | |||
| + | Her er en enkel eksempelkonfigurasjon for å angi sourcetype og transformere logghendelsene.\\ | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [security_logs] | ||
| + | TRANSFORMS-set_sourcetype = set_sourcetype | ||
| + | </ | ||
| + | |||
| + | |||
| + | I transforms.conf kan du definere en transformasjon for å tilordne riktig sourcetype.\\ | ||
| + | <color # | ||
| + | <code class=" | ||
| + | [set_sourcetype] | ||
| + | REGEX = sourcetype = (.+) | ||
| + | DEST_KEY = MetaData: | ||
| + | FORMAT = sourcetype:: | ||
| + | </ | ||
| + | Når du har satt opp konfigurasjonen, | ||
| + | \\ | ||
| + | Merk at dette er et grunnleggende eksempel, og i en produksjonssetting kan du tilpasse konfigurasjonen, | ||
| + | |||
| + | |||
| + | |||
| + | ===== 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 # | ||
| + | <code class=" | ||
| + | index=_internal source=" | ||
| + | | timechart span=1h max(current) as " | ||
| + | </ | ||
| + | |||
| + | Dette søket vil vise køstørrelsen for søkerkøen, | ||
| + | <color # | ||
| + | <code class=" | ||
| + | index=_internal source=" | ||
| + | | timechart span=1h max(current) as " | ||
| + | </ | ||
| + | Dette søket vil vise størrelsen på Parsing Queue og dens kilde (host).\\ | ||
| + | <color # | ||
| + | <code class=" | ||
| + | index=_internal source=" | ||
| + | | stats max(current) as " | ||
| + | </ | ||
| + | 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 # | ||
| + | <code class=" | ||
| + | index=_internal source=" | ||
| + | | 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 ==== | ||
| + | <color # | ||
| + | For å overvåke søkerkøen, | ||
| + | Dette søket gir deg en timechart som viser størrelsen på hver kø for SH1, SH2 og SH3. | ||
| + | \\ | ||
| + | <color # | ||
| + | <code class=" | ||
| + | index=_internal source=" | ||
| + | | timechart span=1h max(current) by host | ||
| + | </ | ||
| + | |||
| + | <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=" | ||
| + | index=_internal source=" | ||
| + | | timechart span=1h max(current) by host | ||
| + | </ | ||
| + | |||
| + | <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 # | ||
| + | Klikk på <color # | ||
| + | Angi en terskel for køstørrelsen, | ||
| + | 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, | ||
| + | <code class=" | ||
| + | \\ | ||
| + | \\ | ||
| + | <color # | ||
| + | For å overvåke Heavy Forwarders, inkludert videresendingskøen og eventuelle transformasjonskøer, | ||
| + | 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=" | ||
| + | index=_internal source=" | ||
| + | | 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): | ||
| + | * Start Splunk: ''/ | ||
| + | * Before setting up SH cluster, enable HTTPS. | ||
| + | * Go to '' | ||
| + | * Restart Splunk. | ||
| + | |||
| + | <code class=" | ||
| + | - In the Deployer, edit ''/ | ||
| + | ``` | ||
| + | [shclustering] | ||
| + | pass4SymmKey = password | ||
| + | shcluster_label = shcluster1 | ||
| + | ``` | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== På hvert søkehode ==== | ||
| + | |||
| + | |||
| + | - In the Search Head Peer Node, execute | ||
| + | |||
| + | ./splunk init shcluster-config -auth < | ||
| + | \\ | ||
| + | Søkehode 1 | ||
| + | <code class=" | ||
| + | ./splunk init shcluster-config -auth admin: | ||
| + | </ | ||
| + | \\ | ||
| + | Søkehode 2 | ||
| + | <code class=" | ||
| + | ./splunk init shcluster-config -auth admin: | ||
| + | </ | ||
| + | \\ | ||
| + | Søkehode 3 | ||
| + | <code class=" | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | |||
| + | Hva som skjer når du kjører den kommandoen er at Splunk vil oppdatere / | ||
| + | Med følgende stanza: | ||
| + | |||
| + | [replication_port:/ | ||
| + | |||
| + | [shclustering] | ||
| + | conf_deploy_fetch_url = https://< | ||
| + | disabled = 0 | ||
| + | mgmt_uri = https://< | ||
| + | pass4SymmKey = <secret key> | ||
| + | shcluster_label = shcluster1 | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | <code class=" | ||
| + | - To select the Captain for the Search Heads, run the following command on every search head peer node you want to include | ||
| + | |||
| + | ``` | ||
| + | | ||
| + | ``` | ||
| + | |||
| + | Example format for three search head peers: | ||
| + | |||
| + | ```diff | ||
| + | + ./splunk bootstrap shcluster-captain -servers_list " | ||
| + | ``` | ||
| + | |||
| + | - To check the search head cluster status, on search head peers execute the following: | ||
| + | |||
| + | ``` | ||
| + | ./splunk show shcluster-status -auth < | ||
| + | ``` | ||
| + | |||
| + | - To connect the SH cluster with a standalone indexer: | ||
| + | |||
| + | In the search head settings, go to '' | ||
| + | |||
| + | - 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://< | ||
| + | ``` | ||
| + | |||
| + | Example: | ||
| + | |||
| + | ```diff | ||
| + | + ./splunk edit cluster-config -mode searchhead -manager_uri https:// | ||
| + | ``` | ||
| + | |||
| + | - Cluster Label: | ||
| + | |||
| + | ``` | ||
| + | splunk edit shcluster-config -shcluster_label <CLUSTER LABEL> | ||
| + | ``` | ||
| + | |||
| + | Reference: [[https:// | ||
| + | Reference: [[https:// | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ===== Sende ut app til SH Cluster ===== | ||
| + | |||
| + | <color # | ||
| + | Untar the file and move to / | ||
| + | |||
| + | |||
| + | <code class=" | ||
| + | / | ||
| + | </ | ||
| + | {{: | ||
| + | |||
| + | |||
| + | <color # | ||
| + | * 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.\\ </ | ||
| + | |||
| + | <code class=" | ||
| + | |||
| + | {{: | ||
test2.1697427390.txt.gz · Sist endret: 2023/10/16 03:36 av admin99
