IBM Support

QRadar: Microsoft Windows Log Sources and Support for SMBv1 and SMBv2 (Updated)

Troubleshooting


Problem

Agentless protocols in QRadar that use Server Message Block version 1 (SMBv1) no longer connect properly due to Microsoft Windows disabling this protocol on all operating systems. This technical note describes a workaround to use an intermediate server.

Symptom

IMPORTANT

IBM has released QRadar protocol RPMs to support both SMBv1 and SMB2 to resolve the connection issues related Microsoft's disabling the SMBv1 connectivity. This release update enhanced the existing SMB protocols for QRadar to allow connections using the SMBv2 file sharing protocol. To enable SMBv2, all five protocol RPMs must be installed in a single command. Administrators can update their protocols to the latest version using the procedure outlined as Option 1: Update QRadar protocols to a version that supports SMBv2 below.

Cause

Microsoft disabled SMBv1 based protocol on all Windows operating systems due to exploits from the WannaCry/WannaCrypt vulnerabilities. Certain QRadar agentless protocols require SMBv1 to allow Event Collectors or Event Processors to connect to the Windows host to collect data. Administrators who have the SMBv1 protocol disabled on a Windows host will no longer be able to establish a connection to Windows hosts. This change by Microsoft affects the following protocols in QRadar:

  • Microsoft IIS (agentless, WinCollect is unaffected)
  • Microsoft Exchange
  • SMB Tail Protocol
  • Microsoft DHCP (agentless, WinCollect is unaffected)
  • Oracle Database Listener

When log sources using these protocols go in to the error state, it might be due to the SMBv1 protocol being disabled. Malicious exploits are targeting SMBv1 protocol as per Microsoft Security Bulletin MS17-010. This critical SMB Server exploit globally disables the SMBv1 on a number of Windows operating systems. This issue affects Windows hosts using QRadar Protocols to collect events, instead of using WinCollect agents.

Diagnosing The Problem

If the QRadar log source using the IIS, Exchange, DHCP, or SMB Tail protocol is in the error state, administrators can verify if SMBv1 is enabled or disabled:

  • Windows Vista or 2008 & Windows 7/2008R2
    Verify the following registry key on the Windows host to determine the status of the SMBv1 protocol. A value of 0 is disabled in the protocol and a value of 1 is enabled: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SMB1
  • Windows 8 & Server 2012
    Administrators can use PowerShell to detect if the SMBv1 enabled or disabled with the following command:
  • if ([bool](Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol)) { Write-Host "SMBv1 is Enabled" } else { write-host "SMBv1 is Disabled" }

  • Windows 10 & Server 2016
    Administrators can verify SMBv1 status using Powershell with the following command:
    Set-SmbServerConfiguration –AuditSmb1Access $true



Resolving The Problem

Option 1 (Recommended): Update QRadar protocols to a version that supports SMBv2
To enable SMBv2, all five protocol RPMs must be installed in a single command. Administrators who attempt to install the protocol files individually will experience installation errors due to rpm dependencies. Administrators must download and install these protocol files using the included instructions. To reduce the impact to users, administrators should consider scheduling a maintenance window to complete this procedure as services are restarted.

    Before you begin, download the following files:
    • PROTOCOL-SmbTailProtocol-<version>.noarch.rpm
    • PROTOCOL-OracleDatabaseListener-<version>.noarch.rpm
    • PROTOCOL-WindowsDHCPProtocol-<version>.noarch.rpm
    • PROTOCOL-WindowsExchangeProtocol-<version>.noarch.rpm
    • PROTOCOL-WindowsIISProtocol-<version>.noarch.rpm

      NOTE: These RPM files are not available through QRadar Auto Updates. Administrators must use the provided links and the procedure below to install the updated protocol RPMs to enable SMBv2 support.

WARNING: A Deploy Full Configuration will temporarily interrupt event and flow collection while services are restarted on all hosts in the deployment. A web server restart will expire the session token, which will log off all users and interrupt reports in progress. Administrators can advise users to manually start reports that are interrupted by a web server restart.


For 7.2.x Consoles:
  1. Download the updated protocol files for QRadar 7.2.x: Fix Central download link for all five protocol rpms
  2. Using SCP or WinSCP, copy the protocol rpm files to the Console.
  3. Using SSH, log in to the Console as the root user.
  4. To install the five protocol rpms, type: yum install -y PROTOCOL-SmbTailProtocol-7.2-20180410083224.noarch.rpm PROTOCOL-OracleDatabaseListener-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsDHCPProtocol-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsExchangeProtocol-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsIISProtocol-7.2-20171212142247.noarch.rpm
  5. From the Admin tab, select Advanced > Deploy Full Configuration.
  6. From the Admin tab, select Advanced > Web Server Restart.

    Results
    After the protocols RPMs are installed, administrators must edit their log source configurations to enable SMBv2. A new user interface field has been added to SMB-based log source configurations to allow administrators to define if the protocol connects to the event source with SMBv1 or SMBv2.


For 7.3.0 & 7.3.1 Consoles:
  1. Download the updated protocol files for QRadar 7.3.x: Fix Central download link for all five protocol rpms
  2. Using SCP or WinSCP, copy the protocol rpm files to the Console.
  3. Using SSH, log in to the Console as the root user.
  4. To install the five protocol rpms, type: yum install -y PROTOCOL-SmbTailProtocol-7.3-20180402125212.noarch.rpm PROTOCOL-OracleDatabaseListener-7.3-20171212192242.noarch.rpm PROTOCOL-WindowsDHCPProtocol-7.3-20171212192242.noarch.rpm PROTOCOL-WindowsExchangeProtocol-7.3-20171212192242.noarch.rpm PROTOCOL-WindowsIISProtocol-7.3-20171212192242.noarch.rpm
  5. From the Admin tab, select Advanced > Deploy Full Configuration.
  6. From the Admin tab, select Advanced > Web Server Restart.

    Results
    After the protocols RPMs are installed, administrators must edit their log source configurations to enable SMBv2. A new user interface field has been added to SMB-based log source configurations to allow administrators to define if the protocol connects to the event source with SMBv1 or SMBv2.

Option 2: Use an intermediate Linux server
This work around uses a Linux intermediate server to mount the remote shares using SMBv2 and make them available via an SMBv1 share to QRadar. The intermediate server is locked down to communicate using SMBv1 and accept these connections from QRadar appliances using firewall rules. The purpose of this procedure is to only allowing SMBv1 between the QRadar appliance and the intermediate server for event collection. Administrators who require SMBv2 per company security policy can use the updated protocols listed in Option 1: Update QRadar protocols to a version that supports SMBv2.

IMPORTANT: The procedures described in this technical note are intended for an intermediate server that is running a Linux distribution. Do NOT run these procedures to create mount points on the QRadar appliance as it will cause event collection issues. This procedure is only intended for a non-QRadar Linux server.

For example:

Figure 1: Example configuration using an intermediate server to collect events using QRadar protocols.


Part 1: Configuring an Intermediate Server Share


This process informs administrators how to create an auto mount to configure a Red Hat Enterprise or CentOS intermediate server share. This share can act as a pass-through for protocols affected by SMBv1 being disabled on most Windows hosts. This procedure works for protocols in QRadar 7.2.x and QRadar 7.3.x and customers are not required to upgrade to collect data.

Procedure
    1. Install a Linux distribution on a 3rd party/intermediate server or virtual machine. NOTE: This cannot be a QRadar appliance or managed host.
    2. Using SSH, log in to the Intermediate Linux server.
    3. To verify that SMB is enabled on the Intermediate Linux server, type: systemctl is-enabled smb
      For example: root@RHEL7-Server ~]# systemctl is-enabled smb disabled

    4. If Step 3 returns the value disabled, type the following command to enable SMB: systemctl enable smb

      [root@RHEL7-Server ~]# systemctl enable smb
      Created symlink from /etc/systemd/system/multi-user.target.wants/smb.service to /usr/lib/systemd/system/smb.service.

    5. To start the smb service, type: systemctl start smb
    6. Using vi editor open /etc/samba/smb.conf and add the following lines:

      [mnt]
      comment = QRadar SMBTail Share
      path = /mnt/smb
      read only = Yes

    7. Save the file by using the Esc key then typing :wq
    8. Create a User and password for a smbuser smbpasswd -a smbuser

      Note: The user smbuser is intended as an example. This is the account name and password that QRadar uses to connect to the SMB1 share on the Linux intermediate server.

    9. To create the directory /mnt/smb, type the following command: mkdir /mnt/smb
    10. To restart the smb service, type: systemctl restart smb

      Results
      SMB is now enabled on the intermediate Linux server. The administrator can now configure firewall rules to restrict communications from selected hosts or services.

    Part 2: Configuring Firewalls

    SMB requires connections to port 445 TCP in the intermediate server. Depending on your Linux distribution, your firewall configuration might be using iptables or firewalld.

    Firewalld

    For firewalld instances in Linux distrubutions based off of Red Hat or CentOS (7.x versions only). These commands should not be run on the QRadar appliance, only the intermediate Linux server.

      1. Type the following command to create a zone for your SMB share:
        firewall-cmd --permanent --zone=public --add-service=samba
      2. Optionally, you can add ports individually:

        firewall-cmd --permanent --add-port=137/tcp
        firewall-cmd --permanent --add-port=138/tcp
        firewall-cmd --permanent --add-port=139/tcp
        firewall-cmd --permanent --add-port=445/tcp
      3. To load the changes in the firewall, type: firewall-cmd --reload

        Results
        The firewall for Red Hat Enterprise 7 or CentOS 7 is enabled to add SMB communications. If the firewall is not reloaded, as in Step 3, these firewall rules will not be enabled. Only select incoming connections are accepted when a zone is set to public. It is recommended that most users to add SMB ports for the service as it can be disabled easily.


    Iptables
    For firewalld instances in Linux distributions based off of Red Hat or CentOS (6.x versions only). These commands should not be run on the QRadar appliance, only the intermediate Linux server.
      1. To add firewall rules in iptables, open the following file in any text editor: /etc/sysconfig/iptables
      2. Add the following lines.
        -A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 137 -j ACCEPT
        -A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 138 -j ACCEPT
        -A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 139 -j ACCEPT
        -A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 445 -j ACCEPT

        Where x.x.x.x is the host sending incoming connections to the Intermediate Linux Server.
      3. Save the file changes.
      4. Reload the updated firewall configuration using this command. service iptables restart


    Part 3: Sharing Your Event Logs

    Windows systems administrators can right-click the target folder containing their IIS, DHCP, Exchange, SQL logs, then select Properties. Click the Sharing tab, which contains the settings to share a folder. Go to the Advanced Sharing and enable the Share this folder check box. Administrators should also verify permissions to ensure that the SMB user configured in Part 1 can access the shared folder. If you are using Windows Server 2016, administrators might need to enable the File Server role. Windows Server 2016 includes the Server Manager application that can be used to create and manage file shares that the Linux intermediate server can access. You must apply a user profile to create a share using Windows Server 2016.

    Part 4: Mounting the SMB File Share


    To automount the Windows folder on the Intermediate Linux using the /etc/fstab file. This procedure is intended as a mount location for the Windows logs on the Linux intermediate server. Auto mounting QRadar to poll for the data. Your log source must use the path defined in the mount point.

      1. Copy the /etc/fstab file to back it up
        cp -p /etc/fstab /etc/fstab.bak
      2. Using vi editor create a credentials file: vi secret.txt
        Note: The credentials file can be a name of your choice.
      3. Add a username and password. The format should look like this
        username=<domain/username_of_host>
        password=<Your_password>
      4. Save the changes using the Esc key they typing :wq
      5. Change the permissions of the file to read write for root only: chmod 600 /root/secret.txt
      6. Add the following line to the bottom of the /etc/fstab file:

        //IP_Address_Windows_Host/Shared_Folder/
        /mnt/smb type cifs credentials=/root/secret.txt,_netdev,uid=0,gid=dba, ro,cache=strict,soft,dir_mode=0755 0 0


        NOTE: The example file path /mnt/smb is only an example and administrators will need to mount each default folder that is used by their Windows hosts for the logs.

        Examples of files that need an individual mount point:
      • For Microsoft Exchange 2016 SMTP logs, the default directory is c$/Program Files/Microsoft/Exchange Server/V15/TransportRoles/Logs/ProtocolLog/ and the mount point could be /mnt/smtp_exchange2016.
      • For Microsoft Exchange 2016 OWA logs, the default directory is c$/inetpub/logs/LogFiles/W3SVC1/ and the mount point could be /mnt/owa_exchange2016.
      • For Microsoft Exchange 2016 SMGTRK logs, the default directory is c$/Program Files/Microsoft/Exchange Server/V15/TransportRoles/Logs/MessageTracking/ and the mount point could be /mnt/msgtrk_exchange2016. .
      • For Microsoft DHCP logs, the default directory is Windows/system32/dhcp/ and the mount point could be /mnt/dhcp.
      • For Microsoft IIS logs, the default errorlog path is Windows/system32/LogFiles/W3SVC1/ and the mount point could be /mnt/iis_logfiles

        Results
        The Administrators might need to repeat this procedure for multiple folders. For example, the Microsoft Exchange protocol supports MSGTRK, OWA, and SMTP logs and each folder needs a mount point. Depending on your collection requirements, repeat this procedure for the other SMB mount points. Your log sources will require an update to reference the intermediate server IP address and any paths for new mount points you create to the new location of Windows log you want to collect.


    Where do you find more information?




[{"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Integrations - 3rd Party","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.3.1;7.3;7.2.8","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
10 May 2019

UID

swg22004891