Overview

Skill Level: Intermediate

NSX Networking, Linux administration, Qradar administration

This solution will help people to integrate VMware NSX Distributed Firewall logsources in IBM Qradar SIEM deployment.

Ingredients

  • VMware NSX infrastrucure using Distributed Firewall (DFW)
  • Linux Server acting as intermediate syslog server receiver
  • IBM Qradar SIEM deployment

Step-by-step

  1. Introduction

    With the introduction of VMware NSX in software defined datacentres a new entity emerged, the Distributed Firewall, it is used for micro segmentation of east west network traffic.
    Differently from the Edge Firewall it isn’t a virtual machine, it is an object implemented by an ESXi kernel module.
    Due to its nature, it writes its messages on the same log file of others ESXi components.
    Configuring a Qradar event collector as log receiver for each ESXi node couldn’t be a good idea, a huge number of messages could reach Qradar contributing to  increase EPS count with some potential effect to EPS license limit.

  2. Architecture overview

    All the ESXi/NSX nodes where there are DFW instancies to monitor send their system logs to a Linux server acting as intermediate syslog server.

     

    In this server there is an rsyslog daemon configured to address all the points mentioned below (A->D).

    A) Receive all ESXI messages
    B) Store them on local file system
    C) Analyse each message payload
    D) Send only Distributed Firewall, remote connection and console messages to Qradar

    I’ll describe this solution in the following steps.

  3. Rsyslog.conf file customisation on Linux Server

    # Provides UDP syslog reception
    $ModLoad imudp
     
    # bind ruleset to tcp listener
    $InputUDPServerBindRuleset remote
    # and activate it
    $UDPServerRun 514
     
    # Remote Logging
    $RuleSet remote
    *.* ?RemoteHost
    # Send only DFW messages – remote connections messages or console messages we receive to Qradar
    if ($msg contains “INET match”) or ($msg contains “sshd”)  or ($msg contains “DCUI”) then {
           |/var/log/logpipes/esx-pipe;TimeHostAndFile
           @qradar_event_collector_fqdn:514
    }
    # end Remote Logging
     
    ###  Store all messages received from ESXi hosts before sending them to Qradar
    $template RemoteHost,”/var/log/hosts/%HOSTNAME%/syslog.log”
     
     
     
    Also send security messages of this Linux server to Qradar as it is a LogSource itself
     
    # Forward some local events to QRadar, too
    authpriv.*    @qradar_event_collector_fqdn:514

    As a result of the above configuration all ESXi messages are stored under /var/log/hosts local directory, here there is a sub-directory for each server and only the messages that match the filter are sent to Qradar event collector.
    To avoid to fill up the space in /var file system a logrotate configuration was put in place. With a proper filesystem sizing, this syslog receiver could be used to maintain n levels of ESXi logs.

     

  4. Alerts

    Furthermore this custom rule and the related Building Block (BB) were implemented, their purpose is to generate an offense on Qradar console whenever there are one or more DFW log sources that are not sending events to Qradar collector for more than one hour.
    Rule name –> “Device stopped sending events – DFW”

    —————— Rule text ————

    Apply “Device Stopped sending events – DFW” on events which are detected by the Local system
    and when none of BB: “Events detected by NSX DistrFW” match in 1 hour(s) after BB: “Events detected by NSX DistrFW” match with the same Log Source

    Building Block name –> “Events detected by NSX DistrFW”

    —————— BB text ————– 

    Apply BB: “Events detected by NSX DistrFW” on events which are detected by the Local system
    and when the event(s) were detected by one or more of NSX DistrFW

    NSX DistrFW is a log source group containing all DFW logsources

     

  5. Correct parsing of messages

    In order to make a correct parsing the logsource type have to be “VmWare NSX”. Optionally a Log Source Extension could be implemented.

  6. Problem determination

    In case of Qradar is not receiving events fron DFW logsources my suggestion is to connect to Linux intermediate server and check

    • Network status and connectivity to Qradar collector – port UDP 514 
    • Rsyslog service functionality
    • Space problems on /var filesystem

Join The Discussion