Syslog og Common Event Format (CEF) via AMA-koblinger for Microsoft Sentinel

Syslog via AMA og Common Event Format (CEF) via AMA-datakoblinger for Microsoft Sentinel filtrere og innta Syslog-meldinger, inkludert meldinger i Common Event Format (CEF), fra Linux maskiner og fra nettverks- og sikkerhetsenheter og -apparater. Disse koblingene installerer Azure Monitor Agent (AMA) på en hvilken som helst Linux maskin som du vil samle Syslog- og/eller CEF-meldinger fra. Denne maskinen kan være opphavsmannen til meldingene, eller det kan være en videresending som samler inn meldinger fra andre maskiner, for eksempel nettverks- eller sikkerhetsenheter og -apparater. Koblingen sender agentinstruksjonene basert på datainnsamlingsregler (DCR-er) som du definerer. DCR-er angir systemene som skal overvåkes, og hvilke typer logger eller meldinger som skal samles inn. De definerer filtre som skal brukes på meldingene før de tas inn, for bedre ytelse og mer effektiv spørring og analyse.

Syslog og CEF er to vanlige formater for logging av data fra forskjellige enheter og programmer. De hjelper systemansvarlige og sikkerhetsanalytikere med å overvåke og feilsøke nettverket og identifisere potensielle trusler eller hendelser.

Hva er Syslog?

Syslog er en standardprotokoll for sending og mottak av meldinger mellom forskjellige enheter eller programmer over et nettverk. Det ble opprinnelig utviklet for Unix-systemer, men det støttes nå mye av ulike plattformer og leverandører. Syslog-meldinger har en forhåndsdefinert struktur som består av en prioritet, et tidsstempel, et vertsnavn, et programnavn, en prosess-ID og en meldingstekst. Syslog-meldinger kan sendes via UDP, TCP eller TLS, avhengig av konfigurasjonen og sikkerhetskravene.

Azure Monitor Agent (AMA) støtter Syslog-meldinger formatert i henhold til RFC 3164 (BSD Syslog) og RFC 5424 (IETF Syslog).

Hva er Common Event Format (CEF)?

CEF eller Common Event Format er et leverandørnøytralt format for logging av data fra nettverks- og sikkerhetsenheter og -apparater, for eksempel brannmurer, rutere, gjenkjennings- og responsløsninger og systemer for inntrengingsgjenkjenning, samt fra andre typer systemer, for eksempel nettservere. En utvidelse av Syslog, det ble utviklet spesielt for sikkerhetsinformasjon og hendelsesbehandling (SIEM) løsninger. CEF-meldinger har en standard topptekst som inneholder informasjon som enhetsleverandøren, enhetsproduktet, enhetsversjonen, hendelsesklassen, alvorsgraden for hendelsen og hendelses-ID-en. CEF-meldinger har også et variabelt antall utvidelser som gir mer informasjon om hendelsen, for eksempel kilde- og mål-IP-adresser, brukernavnet, filnavnet eller handlingen som utføres.

Samling av Syslog- og CEF-meldinger med AMA

Følgende diagrammer illustrerer arkitekturen til Syslog- og CEF-meldingssamlingen i Microsoft Sentinel, ved hjelp av Syslog via AMA og Common Event Format (CEF) via AMA-koblinger.

Enkel maskin (syslog)
Log forwarder (syslog/CEF)

Dette diagrammet viser Syslog-meldinger som samles inn fra én enkelt enkelt Linux virtuell maskin, der Azure Monitor Agent (AMA) er installert.

Diagram over Syslog-samling fra én kilde.

Datainntaksprosessen ved hjelp av Azure Monitor Agent bruker følgende komponenter og dataflyter:

Loggkilder er de ulike Linux VM-er i miljøet ditt som produserer Syslog-meldinger. Disse meldingene samles inn av den lokale Syslog-daemonen på TCP- eller UDP-port 514 (eller en annen port i henhold til dine preferanser).
Den lokale Syslog-daemonen (enten rsyslog eller syslog-ng) samler inn loggmeldingene på TCP- eller UDP-port 514 (eller en annen port i henhold til dine preferanser). Daemonen sender deretter disse loggene til Azure Monitor Agent på to forskjellige måter, avhengig av AMA-versjonen:
- AMA-versjoner 1.28.11 og nyere mottar logger på TCP-port 28330.
- Tidligere versjoner av AMA mottar logger via Unix domain socket.
Hvis du vil bruke en annen port enn 514 for mottak av Syslog/CEF-meldinger, må du kontrollere at portkonfigurasjonen på Syslog-daemonen samsvarer med den til programmet som genererer meldingene.
Den Azure skjermagenten som du installerer på hver Linux VM du vil samle Syslog-meldinger fra, ved å konfigurere datakoblingen. Agenten analyserer loggene og sender dem deretter til Microsoft Sentinel (Log Analytics)-arbeidsområdet.
Arbeidsområdet for Microsoft Sentinel (Log Analytics): Syslog-meldinger som sendes hit, ender opp i Syslog-tabellen, der du kan spørre i loggene og utføre analyser på dem for å oppdage og svare på sikkerhetstrusler.

Dette diagrammet viser Syslog- og CEF-meldinger som samles inn fra en Linux-basert loggsendingsmaskin der Azure Monitor Agent (AMA) er installert. Denne loggen samler Syslog- og CEF-meldinger fra sine opprinnelige maskiner, enheter eller apparater.

Datainntaksprosessen ved hjelp av Azure Monitor Agent bruker følgende komponenter og dataflyter:

Loggkilder er de ulike sikkerhetsenhetene og -apparatene i miljøet ditt som produserer loggmeldinger i CEF-format eller i vanlig Syslog. Disse enhetene er konfigurert til å sende loggmeldinger over TCP- eller UDP-port 514 (eller en annen port i henhold til dine preferanser), ikke til deres lokale Syslog-daemon, men i stedet til Syslog-daemonen på Log Forwarder.
Log forwarder er en dedikert Linux VM som organisasjonen konfigurerer for å samle inn loggmeldinger fra loggkildene Syslog og CEF. Den virtuelle maskinen kan være lokal, i Azure eller i en annen sky. Denne videresendingsloggen har to komponenter:
- Syslog-daemonen (enten rsyslog eller syslog-ng) samler inn loggmeldingene på TCP- eller UDP-port 514 (eller en annen port etter behov). Daemonen sender deretter disse loggene til Azure Monitor Agent på to forskjellige måter, avhengig av AMA-versjonen:
  - AMA-versjoner 1.28.11 og nyere mottar logger på TCP-port 28330.
  - Tidligere versjoner av AMA mottar logger via Unix domain socket.
  Hvis du vil bruke en annen port enn 514 for mottak av Syslog/CEF-meldinger, må du kontrollere at portkonfigurasjonen på Syslog-daemonen samsvarer med den til programmet som genererer meldingene.
- Azure Monitor Agent som du installerer på log forwarder ved å konfigurere Syslog- og/eller CEF-datakoblingene. Agenten analyserer loggene og sender dem deretter til Microsoft Sentinel (Log Analytics)-arbeidsområdet.
Arbeidsområdet for Microsoft Sentinel (Log Analytics): CEF-logger som sendes hit, ender opp i CommonSecurityLog-tabellen og Syslog-meldinger i Syslog-tabellen. Der kan du spørre i loggene og utføre analyser på dem for å oppdage og svare på sikkerhetstrusler.

Obs!

Når du inntar syslogdata ved hjelp av en log forwarder og Azure Monitor Agent (AMA), kan det oppstå inkonsekvenser mellom TimeGenerated feltene og EventTime feltene.

TimeGenerated gjenspeiler UTC-tiden da syslog-meldingen ble behandlet av maskinen som var vert for loggforoversendingen eller samleren.
EventTime trekkes ut fra syslog-toppteksten, som ikke inkluderer tidssoneinformasjon og konverteres til UTC ved hjelp av den lokale tidssoneforskyvningen for forwarder/collector.

Dette kan føre til forskjeller mellom de to feltene når forwarder/collector og enheten som genererer loggen er i forskjellige tidssoner.

Installasjonsprosessen for å samle inn loggmeldinger

Installer den aktuelle løsningen for Syslog eller Common Event Format fra innholdshuben i Microsoft Sentinel. Dette trinnet installerer de respektive datakoblingene Syslog via AMA eller Common Event Format (CEF) via AMA-datakobling. Hvis du vil ha mer informasjon, kan du se Oppdage og administrere Microsoft Sentinel forhåndsdefinert innhold.

Som en del av konfigurasjonsprosessen kan du opprette en regel for datainnsamling og installere Azure Monitor Agent (AMA) på log forwarder. Gjør disse oppgavene enten ved hjelp av Azure- eller Microsoft Defender-portalen, eller ved hjelp av API-en for Azure-overvåkingslogger.

Når du konfigurerer datakoblingen for Microsoft Sentinel i Azure- eller Microsoft Defender-portalen, kan du opprette, administrere og slette DCR-er per arbeidsområde. AMA installeres automatisk på virtuelle maskiner som du velger i koblingskonfigurasjonen.
Du kan også sende HTTP-forespørsler til Logs Ingestion-API-en. Med dette oppsettet kan du opprette, administrere og slette DCR-er. Dette alternativet er mer fleksibelt enn portalen. Med API-en kan du for eksempel filtrere etter bestemte loggnivåer. I Azure- eller Defender-portalen kan du bare velge et minimumsloggnivå. Ulempen med å bruke denne metoden er at du må installere Azure Monitor Agent manuelt på fremoversending av loggen før du oppretter en DCR.

Når du har opprettet DCR og AMA er installert, kjører du installasjonsskriptet på videresendingsprogrammet for loggen. Dette skriptet konfigurerer Syslog-daemonen til å lytte etter meldinger fra andre maskiner, og for å åpne de nødvendige lokale portene. Konfigurer deretter sikkerhetsenhetene eller -apparatene etter behov.

Hvis du vil ha mer informasjon, kan du se følgende artikler:

Unngåelse av datainntaksduplisering

Bruk av samme innretning for både Syslog- og CEF-meldinger kan føre til datainntaksduplisering mellom CommonSecurityLog- og Syslog-tabellene.

Bruk én av disse metodene for å unngå dette scenarioet:

Hvis kildeenheten aktiverer konfigurasjonen av målanlegget: På hver kildemaskin som sender logger til loggforlengeren i CEF-format, redigerer du Syslog-konfigurasjonsfilen for å fjerne fasilitetene som brukes til å sende CEF-meldinger. På denne måten sendes ikke fasilitetene som sendes i CEF, i Syslog. Kontroller at hver DCR du konfigurerer, bruker den relevante innretningen for henholdsvis CEF eller Syslog.

Hvis du vil se et eksempel på hvordan du ordner en DCR til inntak av både Syslog- og CEF-meldinger fra samme agent, kan du gå til Syslog- og CEF-strømmer i samme DCR.
Hvis endring av anlegget for kildeapparatet ikke er aktuelt: Når du har opprettet DCR, kan du legge til inntakstidstransformasjon for å filtrere ut CEF-meldinger fra Syslog-strømmen for å unngå duplisering. Se opplæring: Redigere en datainnsamlingsregel (DCR). Legg til KQL-transformasjon som ligner på følgende eksempel:
```
"transformKql": "  source\n    |  where ProcessName !contains \"CEF\"\n"
```

Neste trinn

Konfigurere datakoblingene

Tilbakemeldinger

Var denne siden nyttig?

Last updated on 2026-04-23