Dela via

Syslog och Common Event Format (CEF) via AMA-anslutningsappar för Microsoft Sentinel

  • Artikel

Syslog via AMA och Common Event Format (CEF) via AMA-dataanslutningar för Microsoft Sentinel filtrerar och matar in Syslog-meddelanden, inklusive meddelanden i Common Event Format (CEF), från Linux-datorer och från nätverk och säkerhetsenheter och enheter. Dessa anslutningsappar installerar Azure Monitor Agent (AMA) på alla Linux-datorer som du vill samla in Syslog- och/eller CEF-meddelanden från. Den här datorn kan vara upphovsman till meddelandena, eller en vidarebefordrare som samlar in meddelanden från andra datorer, till exempel nätverk eller säkerhetsenheter och apparater. Anslutningsappen skickar agentinstruktionerna baserat på de datainsamlingsregler (DCR) som du definierar. DCR anger vilka system som ska övervakas och vilka typer av loggar eller meddelanden som ska samlas in. De definierar filter som ska tillämpas på meddelandena innan de matas in, för bättre prestanda och effektivare frågor och analys.

Syslog och CEF är två vanliga format för loggning av data från olika enheter och program. De hjälper systemadministratörer och säkerhetsanalytiker att övervaka och felsöka nätverket och identifiera potentiella hot eller incidenter.

Vad är Syslog?

Syslog är ett standardprotokoll för att skicka och ta emot meddelanden mellan olika enheter eller program via ett nätverk. Det utvecklades ursprungligen för Unix-system, men stöds nu av olika plattformar och leverantörer. Syslog-meddelanden har en fördefinierad struktur som består av en prioritet, en tidsstämpel, ett värdnamn, ett programnamn, ett process-ID och en meddelandetext. Syslog-meddelanden kan skickas via UDP, TCP eller TLS, beroende på konfiguration och säkerhetskrav.

Azure Monitor-agenten stöder Syslog RFCs 3164 och 5424.

Vad är Common Event Format (CEF)?

CEF, eller Common Event Format, är ett leverantörsneutralt format för loggning av data från nätverk och säkerhetsenheter, till exempel brandväggar, routrar, identifierings- och svarslösningar och intrångsidentifieringssystem samt från andra typer av system som webbservrar. En förlängning av Syslog utvecklades särskilt för siem-lösningar (säkerhetsinformation och händelsehantering). CEF-meddelanden har ett standardhuvud som innehåller information som enhetsleverantören, enhetsprodukten, enhetsversionen, händelseklassen, händelsens allvarlighetsgrad och händelse-ID. CEF-meddelanden har också ett variabelt antal tillägg som ger mer information om händelsen, till exempel källans och målets IP-adresser, användarnamnet, filnamnet eller den åtgärd som vidtagits.

Samling syslog- och CEF-meddelanden med AMA

Följande diagram illustrerar arkitekturen för Syslog- och CEF-meddelandesamlingen i Microsoft Sentinel med hjälp av Syslog via AMA och Common Event Format (CEF) via AMA-anslutningsappar .

Det här diagrammet visar Syslog-meddelanden som samlas in från en enskild virtuell Linux-dator, där Azure Monitor Agent (AMA) är installerad.

Diagram över Syslog-samlingen från en enda källa.

Datainmatningsprocessen med Hjälp av Azure Monitor-agenten använder följande komponenter och dataflöden:

  • Loggkällor är dina olika virtuella Linux-datorer i din miljö som skapar Syslog-meddelanden. Dessa meddelanden samlas in av den lokala Syslog-daemonen på TCP- eller UDP-port 514 (eller en annan port enligt dina önskemål).

  • Den lokala Syslog-daemonen (antingen rsyslog eller syslog-ng) samlar in loggmeddelandena på TCP- eller UDP-port 514 (eller någon annan port enligt dina önskemål). Daemonen skickar sedan dessa loggar till Azure Monitor-agenten på två olika sätt, beroende på AMA-versionen:

    • AMA-versionerna 1.28.11 och senare tar emot loggar på TCP-port 28330.
    • Tidigare versioner av AMA tar emot loggar via Unix-domänsocket.

    Om du vill använda en annan port än 514 för att ta emot Syslog/CEF-meddelanden kontrollerar du att portkonfigurationen på Syslog-daemonen matchar den för programmet som genererar meddelandena.

  • Den Azure Monitor-agent som du installerar på varje virtuell Linux-dator som du vill samla in Syslog-meddelanden från genom att konfigurera dataanslutningen. Agenten parsar loggarna och skickar dem sedan till din Microsoft Sentinel-arbetsyta (Log Analytics).

  • Din Microsoft Sentinel-arbetsyta (Log Analytics): Syslog-meddelanden som skickas här hamnar i tabellen Syslog , där du kan köra frågor mot loggarna och utföra analyser på dem för att identifiera och svara på säkerhetshot.

Installationsprocess för att samla in loggmeddelanden

Från innehållshubben i Microsoft Sentinel installerar du lämplig lösning för Syslog eller Common Event Format. Det här steget installerar respektive dataanslutningar Syslog via AMA eller Common Event Format (CEF) via AMA-dataanslutningen. Mer information finns i Identifiera och hantera innehåll i Microsoft Sentinel out-of-the-box.

Som en del av konfigurationsprocessen skapar du en datainsamlingsregel och installerar Azure Monitor Agent (AMA) på loggvidare. Utför dessa uppgifter antingen med hjälp av Azure- eller Microsoft Defender-portalen eller med hjälp av Inmatnings-API:et för Azure Monitor-loggar.

  • När du konfigurerar dataanslutningen för Microsoft Sentinel i Azure- eller Microsoft Defender-portalen kan du skapa, hantera och ta bort domänkontrollanter per arbetsyta. AMA installeras automatiskt på de virtuella datorer som du väljer i anslutningskonfigurationen.

  • Du kan också skicka HTTP-begäranden till API:et för logginmatning. Med den här konfigurationen kan du skapa, hantera och ta bort domänkontrollanter. Det här alternativet är mer flexibelt än portalen. Med API:et kan du till exempel filtrera efter specifika loggnivåer. I Azure- eller Defender-portalen kan du bara välja en lägsta loggnivå. Nackdelen med att använda den här metoden är att du måste installera Azure Monitor-agenten manuellt på loggvidaren innan du skapar en DCR.

När du har skapat DCR och AMA har installerats kör du skriptet "installation" på loggvidare. Det här skriptet konfigurerar Syslog-daemon för att lyssna efter meddelanden från andra datorer och för att öppna nödvändiga lokala portar. Konfigurera sedan säkerhetsenheterna eller enheterna efter behov.

Mer information finns i följande artiklar:

Undvikande av datainmatningsduplicering

Om du använder samma funktion för både Syslog- och CEF-meddelanden kan det leda till datainmatningsduplicering mellan tabellerna CommonSecurityLog och Syslog.

Undvik det här scenariot genom att använda någon av följande metoder:

  • Om källenheten aktiverar konfiguration av målanläggningen: På varje källdator som skickar loggar till loggvidare i CEF-format redigerar du Syslog-konfigurationsfilen för att ta bort de resurser som används för att skicka CEF-meddelanden. På så sätt skickas inte även de anläggningar som skickas i CEF i Syslog. Kontrollera att varje domänkontrollant som du konfigurerar använder relevant anläggning för CEF respektive Syslog.

    Om du vill se ett exempel på hur du ordnar en DCR för att mata in både Syslog- och CEF-meddelanden från samma agent går du till Syslog- och CEF-strömmar i samma DCR.

  • Om det inte är tillämpligt att ändra resursen för källinstallationen: När du har skapat domänkontrollanten lägger du till inmatningstidstransformation för att filtrera bort CEF-meddelanden från Syslog-dataströmmen för att undvika duplicering. Se Självstudie: Redigera en datainsamlingsregel (DCR). Lägg till KQL-transformering som liknar följande exempel:

    "transformKql": "  source\n    |  where ProcessName !contains \"CEF\"\n"

Nästa steg

Konfigurera dataanslutningarna